GNUstep release policy

From GNUstepWiki

Revision as of 16:00, 4 October 2006; view current revision
←Older revision | Newer revision→

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.