When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
First you need to determine which version number the release will have. Privoxy version numbers consist of three numbers, separated by dots, like in X.Y.Z (e.g. 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 will be 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.
Z, the point or sub version, represents a release of the soft
Privoxy, as an heir to Junkbuster, is an Open Source project and licensed under the GPL. As such, Privoxy development is potentially open to anyone who has the time, knowledge, and desire to contribute in any capacity. Our goals are simply to continue the mission, to improve Privoxy, and to make it available to as wide an audience as possible.
One does not have to be a programmer to contribute. Packaging, testing, and porting, are all important jobs as well.
The first step is to join the developer's mailing list. You can submit your ideas, or even better patches. Patches are best submitted to the Sourceforge tracker set up for this purpose, but can be sent to the list for review too.
You will also need to have a cvs package installed, which will entail having ssh installed as well (which seems to be a requirement of SourceForge), in order to access the cvs repository. Having the GNU build tools is also going to be important (particularly, autoconf and gmake).
For the time being (read, this section is under construction), you can also refer to the extensive comments in the source code. In fact, reading the code is recommended in any case.
When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
First you need to determine which version number the release will have. Privoxy version numbers consist of three numbers, separated by dots, like in X.Y.Z (e.g. 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 will be 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.
Z, the point or sub version, represents a release of the soft
Privoxy, as an heir to Junkbuster, is an Open Source project and licensed under the GPL. As such, Privoxy development is potentially open to anyone who has the time, knowledge, and desire to contribute in any capacity. Our goals are simply to continue the mission, to improve Privoxy, and to make it available to as wide an audience as possible.
One does not have to be a programmer to contribute. Packaging, testing, and porting, are all important jobs as well.
The first step is to join the developer's mailing list. You can submit your ideas, or even better patches. Patches are best submitted to the Sourceforge tracker set up for this purpose, but can be sent to the list for review too.
You will also need to have a cvs package installed, which will entail having ssh installed as well (which seems to be a requirement of SourceForge), in order to access the cvs repository. Having the GNU build tools is also going to be important (particularly, autoconf and gmake).
For the time being (read, this section is under construction), you can also refer to the extensive comments in the source code. In fact, reading the code is recommended in any case.
When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
First you need to determine which version number the release will have. Privoxy version numbers consist of three numbers, separated by dots, like in X.Y.Z (e.g. 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 will be 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.
Z, the point or sub version, represents a release of the soft
Privoxy, as an heir to Junkbuster, is an Open Source project and licensed under the GPL. As such, Privoxy development is potentially open to anyone who has the time, knowledge, and desire to contribute in any capacity. Our goals are simply to continue the mission, to improve Privoxy, and to make it available to as wide an audience as possible.
One does not have to be a programmer to contribute. Packaging, testing, and porting, are all important jobs as well.
The first step is to join the developer's mailing list. You can submit your ideas, or even better patches. Patches are best submitted to the Sourceforge tracker set up for this purpose, but can be sent to the list for review too.
You will also need to have a cvs package installed, which will entail having ssh installed as well (which seems to be a requirement of SourceForge), in order to access the cvs repository. Having the GNU build tools is also going to be important (particularly, autoconf and gmake).
For the time being (read, this section is under construction), you can also refer to the extensive comments in the source code. In fact, reading the code is recommended in any case.
When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
First you need to determine which version number the release will have. Privoxy version numbers consist of three numbers, separated by dots, like in X.Y.Z (e.g. 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 will be 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.
Z, the point or sub version, represents a release of the soft
Privoxy, as an heir to Junkbuster, is an Open Source project and licensed under the GPL. As such, Privoxy development is potentially open to anyone who has the time, knowledge, and desire to contribute in any capacity. Our goals are simply to continue the mission, to improve Privoxy, and to make it available to as wide an audience as possible.
One does not have to be a programmer to contribute. Packaging, testing, and porting, are all important jobs as well.
The first step is to join the developer's mailing list. You can submit your ideas, or even better patches. Patches are best submitted to the Sourceforge tracker set up for this purpose, but can be sent to the list for review too.
You will also need to have a cvs package installed, which will entail having ssh installed as well (which seems to be a requirement of SourceForge), in order to access the cvs repository. Having the GNU build tools is also going to be important (particularly, autoconf and gmake).
For the time being (read, this section is under construction), you can also refer to the extensive comments in the source code. In fact, reading the code is recommended in any case.
When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
First you need to determine which version number the release will have. Privoxy version numbers consist of three numbers, separated by dots, like in X.Y.Z (e.g. 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 will be 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.
Z, the point or sub version, represents a release of the soft