About releasing new versions

Overview

This page describes what to consider the doing a release or a release candidate.

Releases, release candidates and SVN

Packages made from the trunk are generally considered unstable, and we always try to keep it active. Therefore, any release candidate (RC) is first copied from the trunk to a branch with the name of the RC. Packages of this RC should only be made from this branch (and not from the trunk). There is a feature-freeze for the RC, so no new features (unless agreed upon) should be done on the branch, only bug fixes (and documentation update etc).

If more than one RC is necessary, the RC should be renamed to reflect the new number scheme (e.g. 0.3rc1 will be renamed to 0.3rc2). This allows easy access to the history of all files, and keeps the SVN structure clean (it might be worth adding a tag for previous RCs).

The final release is copied from the RC branch to the tag directory (using the release number as name). The branch will be removed to reflect the release number (e.g. 0.3rc2 -> 0.3). For now the branches should be kept in place, since it helps finding problems which might get reported for the release (if they can't be reproduced in the trunk anymore). We might decide on a delete-branch policy later, if this directory gets too full.

If severe bugs make a new minor release necessary (e.g. only fixes for a release, without adding all new patches from the trunk), the new RC for the minor release should be renamed from the release branch (e.g. 0.3 --> 0.3.1rc1).

Patches

  • Any bug fixes to the RC branch should be independently committed to the trunk as well. While this adds a bit overhead of committing a change (since it has to be committed twice), it saves the time and complexity of merging all bug fixes into the trunk when the release is done, and keeps the trunk free for further development.
  • Any new patches not related to the RC or release should be committed to the trunk only.


Naming scheme for packages

All files released on the STK web page should use the following naming scheme:

supertuxkart-VERSION-ARCHITECTURE.SUFFIX

VERSION: E.g. 0.3rc1, 0.3.1rc2, 0.3, SVN1020, ...

ARCHITECTURE: src, win, macosx, linuxi686, linuxppc, ...

SUFFIX: e.g. tar.gz, bz2, dmg, zip, ...

(I am aware that this is currently (during 0.3rc1) not really the case, but we should try to get all of this consistent.

Things to remember

  • After creating a source package and before uploading it, make sure you try to build from this package. It is very easy that some files are missing (e.g. header files were not added to src/Makefile.am), and the source package will not compile.
  • Make sure to update the version number:
    • in configure.ac (from which the define for the sources is created)
    • ChangeLog
    • data/CREDITS
  • Update ChangeLog
  • Update data/CREDITS