About releasing new versions

(Checklist for stable releases)
(Checklist for stable releases)
Line 14: Line 14:
==Checklist for stable releases==
==Checklist for stable releases==
* Give a deadline to translators
* Give a deadline to translators
 +
** Run data/po/update_pot and make sure transifex has the latest pot file for translations.
** 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. They might find issues (e.g. incorrect strings, untranslatable strings, typos) that went undetected before. Once some feedback was received, announce the official string freeze.
** 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. They might find issues (e.g. incorrect strings, untranslatable strings, typos) that went undetected before. Once some feedback was received, announce the official string freeze.
-
* Tested to compile and play under MacOSX.
 
-
* Tested to compile and play under Windows (make sure the icon is available).
 
-
** Do not include the .ilk file, it's only used for linking and otherwise useless.
 
-
* Tested to compile and play under Linux.
 
* After creating a source package, try to build from this package. Sometimes, files are missing.
* After creating a source package, try to build from this package. Sometimes, files are missing.
* 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).
* 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).
 +
* Create a 'tag' for the assets under https://svn.code.sf.net/p/supertuxkart/code/stk-assets-release/
* Run optimize_data.sh.
* Run optimize_data.sh.
* Update ChangeLog file.
* Update ChangeLog file.
-
* Update donations section in CREDITS.
+
* Update data/CREDITS.
 +
** Don't forget the donations section in CREDITS.
 +
** Make sure data/CREDITS is still in UTF (not ascii).
* On Unix systems, make sure all files have appropriate read permissions.
* On Unix systems, make sure all files have appropriate read permissions.
* Update translations from Transifex (after the publicized deadline has been reached).
* Update translations from Transifex (after the publicized deadline has been reached).
** Install the transifex client ( http://docs.transifex.com/developer/client/setup ). On windows place it in the data/po folder. Run ./data/po/pull_from_transifex.sh
** Install the transifex client ( http://docs.transifex.com/developer/client/setup ). On windows place it in the data/po folder. Run ./data/po/pull_from_transifex.sh
 +
** Run data/po/update_po_authors.py on all(!) .po files to update the credit sections for translators.
** Regenerate the Chinese font files:
** Regenerate the Chinese font files:
*** A list of all Asian fonts is in tools/font_tool/po_list (check that it is up to date).
*** A list of all Asian fonts is in tools/font_tool/po_list (check that it is up to date).
*** Run "FontTool.exe tools/font_tool/po_list" (if everything goes right you'll see "Opened list file xxx ... Opened xxx.po ..." in the console).
*** Run "FontTool.exe tools/font_tool/po_list" (if everything goes right you'll see "Opened list file xxx ... Opened xxx.po ..." in the console).
*** [[Fonts | See here]] for how to generate the font files.
*** [[Fonts | See here]] for how to generate the font files.
-
** Run data/po/update_po
 
* Make sure to update the version number:
* Make sure to update the version number:
** CMakeLists.txt
** CMakeLists.txt
Line 39: Line 39:
** Create a file data/supertuxkart.VERSION  (same as 'supertuxkart.' + STK_VERSION from constant.cpp) - and delete any previous file. This file is used by stk to make sure it is reading the correct assets input data.
** Create a file data/supertuxkart.VERSION  (same as 'supertuxkart.' + STK_VERSION from constant.cpp) - and delete any previous file. This file is used by stk to make sure it is reading the correct assets input data.
** data/SuperTuxKart-Info.plist
** data/SuperTuxKart-Info.plist
-
* Update ChangeLog.
 
-
* Update data/CREDITS.
 
-
** Make sure data/CREDITS is still in UTF (not ascii).
 
-
* Test to run when no sound card is available. Sound should be disabled and continue, not crash.
 
* Check that the addon server has all achievements defined (data/achievements.xml should be in sync with table v2_achievements).
* Check that the addon server has all achievements defined (data/achievements.xml should be in sync with table v2_achievements).
-
Upload packages, then :
 
-
* Update the Downloads Page
 
-
* Update the default file settings at sourceforge
 
For binary packages (esp. linux):
For binary packages (esp. linux):
* Don't include INSTALL, it confuses people
* Don't include INSTALL, it confuses people
 +
For Windows:
 +
* Do not include the .ilk file, it's only used for linking and otherwise useless.
 +
 +
 +
Upload packages, then :
 +
* Update the Downloads Page
 +
* Update the default file settings at sourceforge
== Naming scheme for packages ==
== Naming scheme for packages ==

Revision as of 23:06, 18 October 2015

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

Checklist for stable releases


For binary packages (esp. linux):

For Windows:


Upload packages, then :

Naming scheme for packages

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

supertuxkart-<VERSION>-<ARCHITECTURE>.<FILE EXTENSION>

VERSION:

ARCHITECTURE:

FILE EXTENSION:


Examples of full package file names: supertuxkart-0.3-linuxi586.tar.bz2, supertuxkart-git2110-macosx.dmg, supertuxkart-0.4-rc1-win.zip

Where to advertise a new release

This page collects web pages that should be informed about a new SuperTuxKart release. If you add a note to a board, blog, web page, please add the URL here, and add your name (hoping that in upcoming releases you can contact the same pages again).

Mark what's done with Done.png


Retrieved from "http://supertuxkart.sourceforge.net/About_releasing_new_versions"

User Tools