About releasing new versions
Contents |
Unstable releases vs stable releases
Any packages released from the trunk are considered 'unstable'. They are not meant to be broken, but fewer steps are taken to produce it, skipping the ones that often catch bugs, which also makes them easier and faster to make, so they are better suited to make it easier to test new features quickly. The process is simply to make a package for general distribution from source of the trunk.
To make a stable package, first a separate branch must be created in the source tree, by copying the current trunk to a branch, as a 'release candidate'(RC), named with the version number plus the RC number, for example, 0.3rc1. Afterwards, only bug fixes are committed to that branch (unless we all agree to introduce a feature) on this release candidate; neither major changes in other areas of the game, thought documentation and artwork updates are fine. If we decide we need more testing after doing all the modifications to the release candidate, the same RC should be renamed to reflect the new number scheme (e.g. 0.3rc1 would 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. Also, the license under which STK is released requires us to provide the source code for at least 3 years for any binaries we provide.
Committing changes during the preparation of a stable release
- Any bug fixes to the RC branch should be independently committed to the trunk as well, just as they should be committed to the RC branch if it's meant for the trunk, but it applies to the RC. 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.
Checklist for stable releases
- Tested to compile and play under MacOSX.
- Tested to compile and play under Windows.
- Tested to compile and play under Linux (here for completeness, as most developers run Linux).
- After creating a source package, try to build from this package. Sometimes, files are missed.
- Make sure to update the version number:
- in configure.ac (from which the define for the sources is created. This number should not have any spaces in it, otherwise "make dist" will fail)
- ChangeLog
- NEWS
- data/CREDITS
- src/ide/vc8/supertuxkart.vcproj
- Update ChangeLog
- Update data/CREDITS
- Test to run when no sound card is available. Sound should be disabled and continue, not crash.
Naming scheme for packages
All files released on the STK web page should use the following naming scheme:
supertuxkart-<VERSION>-<ARCHITECTURE>.<FILE EXTENSION>
VERSION:
- Release candidates: the version number of the next stable release + rc + release candidate number. Examples: 0.3rc1 or 0.3.1rc2
- Stable release examples: the version number. Examples: 0.3, 0.4
- Unstable release examples: SVN + SVN revision number. Examples: SVN1020, SVN2418
ARCHITECTURE:
- Source packages: src
- Windows binary packages: win
- Mac OS X binary packages: macosx
- Linux x86 packages: linux + required processor type. Examples: linuxi586, linuxi686, linuxppc
FILE EXTENSION:
- Depends on the file type. Examples: tar.gz, tar.bz2, dmg, zip, ...
Examples of full package file names: supertuxkart-0.3-linuxi586.tar.bz2, supertuxkart-SVN2110-macosx.dmg, supertuxkart-0.4rc1-win.zip
Uploading packages to sourceforge
You a file to be automatically downloaded depending on the OS used (e.g. a windows, linux, mac version). Anybody just clicking on the download link from the project overview page will automatically get this specific version offered (with the option to download something else of course).
You can do this by going to admin->file release -> create/edit download page.