GNUstep release policy

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 subminor version numbers.

Standard release procedure (backward compatible with previous version)

• tag the version for release using the name_major_minor_subminor convention.
• rename the old 'stable' branch to use the name_major_minor convention.
• copy the version for release to form a new 'stable' branch
• make tarballs and installation packages
• bump the subminor version number in trunk
• put release on ftp site and publicise

Standard release procedure (NOT backward compatible with previous version)

• bump the minor version number and SONAME and reset the subminor number to zero
• tag the version for release using the name_major_minor_subminor convention.
• rename the old 'stable' branch to use the name_major_minor convention.
• copy the version for release to frm a new 'stable' branch
• make tarballs and installation packages
• bump the minor version number and SONAME and reset the subminor number to zero
• tag the version for release as 'unstable' using the name_major_minor_subminor convention.
• put releases on ftp site and publicise

Bugfix release procedure

• apply bugfixes to the 'stable' branch
• bump the subminor version number (in the 'stable' branch)
• tag the version for release using the name_major_minor_subminor convention.
• make tarballs and installation packages
• put on ftp site and publicise

'bugfix' releases are only made in 'stable' release families, and these are the only sort of releases we make in those families.