Make sure to update the version number:.po files to update the credit sections for translators. Run data/po/update_po_authors.py on all(!).On windows place it in the data/po folder. Update translations from Transifex (after the publicized deadline has been reached).On Unix systems, make sure all files have appropriate read permissions.Make sure data/CREDITS is still in UTF8 (not ascii).

Don’t forget the donations section in CREDITS.

Document the assets svn version in doc/assets_version (so that we can keep track of which assets version was used for which stk release, we don’t have branches directories for assets due to their size).

After creating a source package, try to build from this package.Creating a quick (~1min30) video showcasing new features/tracks/etc.Once some feedback was received, announce the official string freeze. incorrect strings, untranslatable strings, typos) that went undetected before. This should involve two steps: first contact translators and make them aware that a string freeze will happen in the near future, and ask them for feedback.Run data/po/update_pot.sh and make sure transifex has the latest pot file for translations.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.Īny new patches not related to the RC or release should be committed to master only. Committing changes during the preparation of a stable releaseĪny bug fixes to the RC branch should be cherry-picked to master as well (or vice versa). 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. We might decide on a delete-branch policy later.

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). The final release is a new branch copied from the last RC branch, and a tag for the release is created. This allows easy access to the history of all files (it might be worth adding a tag for RCs). a new branch 1.3-rc2 created from 1.3-rc1). If we decide we need more testing after doing all the modifications to the release candidate, a new branch is created from the previous rc branch (e.g. Afterwards, only bug fixes are committed to that branch (unless we all agree to introduce a feature) on this release candidate no changes in other areas of the game, thought documentation and artwork updates are fine. To make a stable package, first a separate branch off master 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. The process is simply to make a package for general distribution from source of the trunk. 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.

Committing changes during the preparation of a stable releaseĪny packages released from the trunk are considered ‘unstable’.

Supertuxkart 1.3