tayatu.blogg.se - Supertux version 0.3.1

Supertux version 0.3.1 update#
Supertux version 0.3.1 code#

tools/windows_installer/supertuxkart*.nsi (two nsi files, check all four VERSION_* defines).

Supertux version 0.3.1 update#

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 UTF (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.

Send email to supertuxkart-core and/or supertuxkart-dev to keep people up-to-date.

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 and make sure transifex has the latest pot file for translations.

Any new patches not related to the RC or release should be committed to master only.

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 bug fixes to the RC branch should be cherry-picked to master as well (or vice versa).

Committing changes during the preparation of a stable release

Supertux version 0.3.1 code#

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.