[Openswan dev] changes to release numbering
mcr at xelerance.com
Wed Nov 1 16:05:03 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Starting with the 2.5.00 and 3.0.00 release, we are clarifying what
different release numbers mean.
Releases are numbered M.X.YY.
During Y==0 releases, we may introduce new functionality.
These releases are to be considered "testing" (in debian parlance)
During Y!=0 releases, we may not introduce new functionality, and these
releases are to be considered "stable" (in debian parlance).
Releases where X==0 are to be considered "unstable". We reserve the
right to replace entire subsystems, remove functionality,
change configuration file formats, etc.
2.2.1 --- (M=2, X=2, Y=1) is a *STABLE* RELEASE.
2.3.0 --- (M=2, X=3, Y=0) is a *TESTING* RELEASE.
2.3.1 --- (M=2, X=3, Y=1) is a *STABLE* RELEASE.
3.0.1 --- (M=3, X=0, Y=1) is an *UNSTABLE* RELEASE, even though Y!=0.
Furthermore, when X==0, it is possible that there is newer
(but FAR LESS stable) code than a higher numbered release with X!=0.
That is, one could see a release pattern like:
3.0.1 - unstable
3.0.2 - unstable
3.1.0 - testing
3.0.3 - unstable
3.1.1 - stable
3.0.27 - unstable
3.1.2 - stable
3.2.0 - testing
3.0.33 - unstable
3.1.3 - stable
3.2.1 - stable
3.0.28 - unstable (maybe from a different branch!)
We expect that if someone was running 3.1.3, that an upgrade to 3.2.1
should be considered very safe. We promise that we will not change
any significant functionality or default in a minor number change.
The config files will be upwards compatible, and to the extent possible,
downward compatible -- i.e. we won't replace/upgrade any files in 3.2.1
such that it won't also work with 3.1.3.
We hope that this is clear enough to package managers.
It is very likely that once 3.2.1 ships, that there will be NO FURTHER
SECURITY PATCHES to 3.1.3!
The digits "Y" may go as large as 99, and will have leading zeros.
We will do a new X or Y-level release 4 times a year, possibly more often if
we need to fix bugs.
The #public/2.5.0drY branch shall be released as 2.5.00. Once it has
become stable, it will become 2.5.01, etc. and become the stable version.
At nearly the same time, there will be a 3.0.00 release from the "260ocf"
branch. Once this is more stable, it will become 3.1.xx.
At the same time, a "fsm" branch will begin to be released as 3.0.NN
(NN =~ 20), which when it is ready, will start merging code into a 3.2.00.
There will not be any more "DR" releases.
If we find that we need to cycle at something that is definitely unstable, we
will do so at the previous "M.0" level.
**PACKAGE MANAGER EXPECTATIONS**
The message to Fedora and Debian should be:
1) include Y==0 releases in "testing" at your discretion.
2) there is no significant functional changes or stability changes
between M.X.Y and M.X+1.Y, for Y!=0.
Setting Y=0 is a sign that we may have refactored or revised some
piece of the system, and we are indicating caution. Users should
be able to trust that M.X+1.Y, Y>=1 will be a drop-in replacement for
We will try to always do a M.X.1 release within 2 months of a M.X.0
release. Those are to be considered stable.
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Dev