Privoxy Developer Manual
Copyright
- © 2001-2023 by Privoxy Developers
Please note that this document is constantly evolving. This copy represents the state at the release of - version 3.0.35. You can find the latest version of the this manual at https://www.privoxy.org/developer-manual/. Please have a look at the contact section in the user manual if you are interested in contacting the developers.
diff --git a/doc/webserver/developer-manual/newrelease.html b/doc/webserver/developer-manual/newrelease.html index f973801d..f8ff3799 100644 --- a/doc/webserver/developer-manual/newrelease.html +++ b/doc/webserver/developer-manual/newrelease.html @@ -40,47 +40,18 @@ 3.0.0), where:-
-
X, the version major, is rarely ever changed. It is increased by one if turning a development branch into - stable substantially changes the functionality, user interface or configuration syntax. Majors 1 and 2 were - Junkbuster, and 3 is the first stable Privoxy release.
+X, the version major, is rarely ever changed. Majors 1 and 2 were Junkbuster, and 3 is the first stable Privoxy + release.
-
-
Y, the version minor, represents the branch within the major version. At any point in time, there are two - branches being maintained: The stable branch, with an even minor, say, 2N, in which no functionality is being - added and only bug-fixes are made, and 2N+1, the development branch, in which the further development of - Privoxy takes place. This enables us to turn the code upside down and inside - out, while at the same time providing and maintaining a stable version. The minor is reset to zero (and one) - when the major is incremented. When a development branch has matured to the point where it can be turned into - stable, the old stable branch 2N is given up (i.e. no longer maintained), the former development branch 2N+1 - becomes the new stable branch 2N+2, and a new development branch 2N+3 is opened.
+Y, the version minor, is increased for every release except for pure bug fix releases in which case only + Z, the point or sub version, is increased.
-
-
Z, the point or sub version, represents a release of the software within a branch. It is therefore - incremented immediately after each software release. The point version is reset to zero when the minor - changes.
-Stable branches work a little differently, since there should be little to no development happening in - such branches. Remember, only bugfixes, which presumably should have had some testing before being committed. - Stable branches will then have their version reported as 0.0.0, during that period - between releases when changes are being added. This is to denote that this code is not for release. Then as the release nears, the version is bumped - according: e.g. 3.0.1 -> 0.0.0 -> 3.0.2.
+The point version is reset to zero when the minor changes.
In summary, the main Git trunk is the development branch where new features are being worked on for the next - stable series. This should almost always be where the most activity takes place. There is always at least one - stable branch from the trunk, e.g now it is 3.0, which is only used to release stable - versions. Once the initial *.0 release of the stable branch has been done, then as a rule, only bugfixes that - have had prior testing should be committed to the stable branch. Once there are enough bugfixes to justify a new - release, the version of this branch is again incremented Example: 3.0.0 -> 3.0.1 -> 3.0.2, etc are all - stable releases from within the stable branch. 3.1.x is currently the main trunk, and where work on 3.2.x is - taking place. If any questions, please post to the devel list before committing to a stable branch!
-Developers should remember too that if they commit a bugfix to the stable branch, this will more than likely - require a separate submission to the main trunk, since these are separate development trees within Git. If you - are working on both, then this would require at least two separate check outs (i.e main trunk, and the stable release branch, which is v_3_0_branch at the moment).
6.2. Before the Release
@@ -492,7 +463,7 @@
- dch -v 3.0.35-1+ dch -v 4.0.0-1 |
- lintian -iI ../build-area/privoxy_3.0.35-1_amd64.changes+ lintian -iI ../build-area/privoxy_4.0.0-1_amd64.changes |
sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_3.0.35-1.dsc+ "PROGRAMLISTING"> sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_4.0.0-1.dsc
autopkgtest /var/cache/pbuilder/result/privoxy_3.0.35-1_amd64.changes -s -- schroot sid+ "PROGRAMLISTING"> autopkgtest /var/cache/pbuilder/result/privoxy_4.0.0-1_amd64.changes -s -- schroot sid
Or just push the changes to salsa.debian.org, where a CI pipeline is defined for the package, that builds and tests it.
If everything is okay, run cowbuilder with i386 and amd64 environments for current Debian stable release and - build privoxy_3.0.35-1_i386.deb and privoxy_3.0.35-1_amd64.deb. Then sign both files:
+ build privoxy_4.0.0-1_i386.deb and privoxy_4.0.0-1_amd64.deb. Then sign both files:
- gpg --detach-sign --armor privoxy_3.0.35-1_i386.deb - gpg --detach-sign --armor privoxy_3.0.35-1_amd64.deb+ gpg --detach-sign --armor privoxy_4.0.0-1_i386.deb + gpg --detach-sign --armor privoxy_4.0.0-1_amd64.deb |
7. Privoxy Copyright, License and History
-Copyright © 2001-2023 by Privoxy Developers <Copyright © 2001-2025 by Privoxy Developers <privoxy-devel@lists.privoxy.org>
Some source code is based on code Copyright © 1997 by Anonymous Coders and Junkbusters, Inc.
Portions of this document are "borrowed" from the original If you have any questions regarding donations please mail to either the public user mailing list or, if it's a private matter, to Fabian Keil (Privoxy's SPI liaison) directly.
+If you want to support Fabian directly, you can also buy a Privoxy Moral License.
Please note that this document is a work in progress. This copy represents the state at the release of - version 3.0.35. You can find the latest version of the document at https://www.privoxy.org/faq/. Please see the Contact section if you want to contact the developers.
Table 1. Operating system support for binaries provided by Privoxy team members
