Releases are named by their major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo_1_2_3. The library (SONAME) versions is changed when the major or minor version number of a release changes, but not the subminor number. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4.

+

Releases are named by their major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo-1_2_3. The library (SONAME) versions is changed when the major or minor version number of a release changes, but not the subminor number. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4.

* bump the minor version number and SONAME and reset the subminor number to zero (minor should be an even number)

* bump the minor version number and SONAME and reset the subminor number to zero (minor should be an even number)

-

* tag the version for release using the name_major_minor_subminor convention.

+

* tag the version for release using the name-major_minor_subminor convention.

* rename the old 'stable' branch to use the stable-major_minor_subminor convention.

* rename the old 'stable' branch to use the stable-major_minor_subminor convention.

* copy the version for release to form a new 'stable' branch

* copy the version for release to form a new 'stable' branch

Revision as of 19:29, 12 April 2007

Release Version Numbering scheme

Releases are named by their major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo-1_2_3. The library (SONAME) versions is changed when the major or minor version number of a release changes, but not the subminor number. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4.

Policy on changing version numbers

The minor version number is changed (and therefore the library version) when we break backward compatibility . This will mean that most releases we make will only change the subminor number rather than the minor number even where we have added substantial new features. While we realise that this has a problem with public perception being that the project is dead because it never makes 'big' new releases, we think it's better to address the problem with improved publicity of what's in the new release rather than by hoping that a big version number change will do it for us. On the rare occasion where we want a big public change, we would change the major version number (and of course SONAME).

Release stability policy

We advertise a 'stable' release every time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. The vast majority of people would probably just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low. 'stable' releases will be those with even minor version numbers.