Difference between revisions of "GNUstep release policy"

Revision as of 02:10, 22 October 2006

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.
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 as 'stable' using the name_major_minor_subminor convention.
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

if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0
apply bugfixes to the branch
tag the branch as foo_1_2_0-1
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.

@@ Line 1: / Line 1: @@
-When making a release, make a branch in svn into which any bugfixes will be applied.
+'''Release Version Numbering scheme'''
-Immediately after making the release, increase the minor version number in trunk.
-After a release, if we need to make a bugfix release, we do it by incrementing the subminor version number in the branch and releasing a snapshot of the branch at that point. We don't add new features in bugfixes, so there is no issue with version macros.
+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.
-Any API changes added to trunk will be in the next non-bugfix release, so the version number to put in the macros is the version number of the current trunk code.
+'''Policy on changing version numbers'''
-It is possible that the maintainer may decide not to actually release the version in trunk, but to jump directly to a new major version number ... this does not matter, since the new version number is guaranteed to be at least as high as the value put in trunk immediately after the last release.
+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).
-eg.
+'''Release stability policy'''
-* Release 1.14.0
-* Make a branch of 1.14.0 for bug fixes only
-* Move trunk to 1.15.0 (Change the Version file)
-* Added API is tagged as available from 1.15.0 onwards
-Note: There is no such thing as stable and non-stable releases. All releases are considered ''stable'' although
+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.
-any important bug fixes would almost imediately be released as a bug fix (subminor) release, so these would
-be considered more stable than a X.X.0 (minor or major) release.
+'''Standard release procedure (backward compatible with previous version)'''
+* tag the version for release using the name_major_minor_subminor convention.
+* 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 as 'stable' using the name_major_minor_subminor convention.
+* 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'''
+* if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0
+* apply bugfixes to the branch
+* tag the branch as foo_1_2_0-1
+* 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.
 [[Category:Project procedures]]

Difference between revisions of "GNUstep release policy"

Revision as of 02:10, 22 October 2006

Navigation menu

Search