Difference between revisions of "GNUstep release policy"

From GNUstepWiki
Jump to navigation Jump to search
(GNUstep release policy)
 
 
(8 intermediate revisions by 2 users not shown)
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.  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.
−
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 (NOT backward compatible with previous version - new stable release)'''  
 +
* 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
 +
* put release on ftp site and publicise
 +
* set the subminor version in trunk to 1
 +
 
 +
'''Standard release procedure (backward compatible with previous version'''
 +
* 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 subminor version number in the trunk
 +
* put release on ftp site and publicise
 +
* increment the subminor version in trunk to 1
 +
 
 +
'''Bugfix release procedure (on stable branch)'''
 +
* apply bugfixes to the 'stable' branch
 +
* set the subminor version number in the 'stable' branch to the current value in trunk
 +
* increment the subminor version number 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]]
 
[[Category:Project procedures]]

Latest revision as of 12:23, 31 January 2012

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. 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
  • 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
  • put release on ftp site and publicise
  • set the subminor version in trunk to 1

Standard release procedure (backward compatible with previous version

  • 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 subminor version number in the trunk
  • put release on ftp site and publicise
  • increment the subminor version in trunk to 1

Bugfix release procedure (on stable branch)

  • apply bugfixes to the 'stable' branch
  • set the subminor version number in the 'stable' branch to the current value in trunk
  • increment the subminor version number 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
Retrieved from "https://mediawiki.gnustep.org/index.php?title=GNUstep_release_policy&oldid=6257"