Difference between revisions of "GNUstep release policy"
m (Fix some tag names) |
|||
| Line 9: | Line 9: | ||
'''Release stability policy''' | '''Release stability policy''' | ||
| − | We advertise a 'stable' release ''every'' time we break backward compatibility. | + | 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)''' | '''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 | + | * 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. | ||
| − | |||
* copy the version for release to form 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 | ||
| − | * | + | * put release on ftp site and publicise |
| − | + | * set the subminor version in trunk to 1 | |
| − | |||
| − | '''Standard release procedure (backward compatible with previous version | + | '''Standard release procedure (backward compatible with previous version''' |
* tag the version for release using the name_major_minor_subminor convention. | * 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 | * make tarballs and installation packages | ||
* bump the subminor version number in the trunk | * bump the subminor version number in the trunk | ||
* put release on ftp site and publicise | * put release on ftp site and publicise | ||
| + | * increment the subminor version in trunk to 1 | ||
'''Bugfix release procedure (on stable branch)''' | '''Bugfix release procedure (on stable branch)''' | ||
* apply bugfixes to the '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. | * 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 | ||
| − | |||
[[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