Difference between revisions of "GNUstep release policy"

From GNUstepWiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
'''Release Version Numbering scheme'''
 
'''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'''  
 
'''Policy on changing version numbers'''  
Line 9: Line 9:
 
'''Release stability policy'''  
 
'''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.  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 (backward compatible with previous version)'''  
+
'''Standard release procedure (NOT backward compatible with previous version - new stable release)'''  
−
* tag the version for release using the name_major_minor_subminor convention.
+
* bump the minor version number and SONAME and reset the subminor number to zero
−
* rename the old 'stable' branch to use the name_major_minor convention.
+
* tag the version for release using the name-major_minor_subminor 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  
 
* make tarballs and installation packages  
−
* bump the subminor version number in trunk
 
 
* put release on ftp site and publicise
 
* put release on ftp site and publicise
 +
* set the subminor version in trunk to 1
  
−
'''Standard release procedure (NOT backward compatible with previous version)'''  
+
'''Standard release procedure (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.
 
* 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
−
* copy the version for release to frm a new 'stable' branch
 
 
* make tarballs and installation packages  
 
* make tarballs and installation packages  
−
* bump the minor version number and SONAME and reset the subminor number to zero
+
* bump the subminor version number in the trunk
−
* tag the version for release as 'unstable' using the name_major_minor_subminor convention.
+
* put release on ftp site and publicise
−
* put releases on ftp site and publicise
+
* increment the subminor version in trunk to 1
  
−
'''Bugfix release procedure'''  
+
'''Bugfix release procedure (on stable branch)'''  
 
* apply bugfixes to the '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
 +
* increment the subminor version number in trunk
 
* tag the version for release using the name_major_minor_subminor convention.
 
* tag the version for release using the name_major_minor_subminor convention.
 
* make tarballs and installation packages  
 
* make tarballs and installation packages  
 
* put on ftp site and publicise  
 
* 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]]
 
[[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"