GNUstep release policy - Revision history

Rfm at 12:23, 31 January 2012

2012-01-31T12:23:57Z

Fedor: Fix some tag names

2007-04-12T19:29:13Z

Fix some tag names

Fedor at 19:11, 12 April 2007

2007-04-12T19:11:23Z

Fedor at 15:29, 12 April 2007

2007-04-12T15:29:18Z

Fedor: More release clraifications

2007-04-12T15:25:52Z

More release clraifications

Fedor: Clarify release checklist

2007-04-12T15:16:08Z

Clarify release checklist

Rfm: fix typo

2007-01-02T06:04:57Z

fix typo

Rfm at 11:32, 28 December 2006

2006-12-28T11:32:24Z

Fedor: Updated release policy

2006-10-22T02:10:05Z

Updated release policy

Fedor: GNUstep release policy

2006-10-04T16:00:56Z

GNUstep release policy

New page

When making a release, make a branch in svn into which any bugfixes will be applied.
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.

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.

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.

eg.
* 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
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.

[[Category:Project procedures]]

@@ Line 9: / Line 9: @@
 '''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.
+We advertise a 'stable' release ''every'' time we break backward compatibility.  We no longer advertise 'unstable/development' releases. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and start working on 1.4.1 in subversion trunk.  All releases (if any) in the 1.4 family would then be considered either bugfix or development releases.
 '''Standard release procedure (NOT backward compatible with previous version - new stable release)'''
-* 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
 * tag the version for release using the name-major_minor_subminor convention.
 * copy the version for release to form a new 'stable' branch
 * make tarballs and installation packages
-* bump the minor version number and SONAME and reset the subminor number to zero (minor should be an odd number)
+* put release on ftp site and publicise
-* tag the version for release as 'unstable' using the name_major_minor_subminor convention.
+* set the subminor version in trunk to 1
-'''Standard release procedure (backward compatible with previous version - changes on trunk (unstable))'''
+'''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 the trunk
 * put release on ftp site and publicise
 '''Bugfix release procedure (on stable branch)'''
 * apply bugfixes to the 'stable' branch
-* bump the subminor version number (in the 'stable' branch)
+* set the subminor version number in the 'stable' branch to the current value in trunk
 * tag the version for release using the name_major_minor_subminor convention.
 * make tarballs and installation packages
 * put on ftp site and publicise
 [[Category:Project procedures]]

@@ Line 1: / Line 1: @@
 '''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.
+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'''
@@ Line 13: / Line 13: @@
 '''Standard release procedure (NOT backward compatible with previous version - new stable release)'''
 * 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.
 * copy the version for release to form a new 'stable' branch

@@ Line 21: / Line 21: @@
 * put releases on ftp site and publicise
-'''Standard release procedure (backward compatible with previous version - bugfix on trunk (unstable))'''
+'''Standard release procedure (backward compatible with previous version - changes on trunk (unstable))'''
 * tag the version for release using the name_major_minor_subminor convention.
 * make tarballs and installation packages

@@ Line 21: / Line 21: @@
 * put releases on ftp site and publicise
-'''Standard release procedure (backward compatible with previous version - bugfix on unstable branch)'''
+'''Standard release procedure (backward compatible with previous version - bugfix on trunk (unstable))'''
 * tag the version for release using the name_major_minor_subminor convention.
 * make tarballs and installation packages

@@ Line 9: / Line 9: @@
 '''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.
+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.
-'''Standard release procedure (backward compatible with previous version)'''
+'''Standard release procedure (NOT backward compatible with previous version - new stable release)'''
 * 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.
@@ Line 27: / Line 21: @@
 * put releases on ftp site and publicise
-'''Bugfix release procedure'''
+'''Standard release procedure (backward compatible with previous version - bugfix on unstable branch)'''
 * apply bugfixes to the 'stable' branch
 * bump the subminor version number (in the 'stable' branch)

@@ Line 14: / Line 14: @@
 * 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
+* copy the version for release to form a new 'stable' branch
 * make tarballs and installation packages
 * bump the subminor version number in trunk