Last modified 7 months ago Last modified on 10/28/11 16:58:04

Release Checklist

Table of Contents

  1. First Steps
  2. Testing
  3. Bump version numbers
    1. ChangeLog
    2. configure.ac
    3. Make it default to release builds.
    4. dpkg changelog
    5. autorevision.conf
    6. win32/warzone2100.rc
    7. [source:lib/framework/config-macosx.h@master …
    8. lib/netplay/netplay.cpp
  4. Mac Builds
  5. Add new version to the Bug Tracker
  6. Sync trunk
    1. Update trunk ChangeLog
    2. Update trunk Debian ChangeLog
  7. Create a source tarball
  8. Create binary packages
    1. Create an NSIS installer
  9. Do a crash handler test!
  10. Wait
  11. Finalise the Tag
  12. Wiki: Releases-article and front page
  13. Announce the release

First Steps

The first thing to do is make a temporary branch to hold your changes: 

git checkout -b todo/3.0_beta2
git push {YourPersonalFork} todo/3.0_beta2

Where 3.0_beta2 is the name of the tag you want to make.
NOTE: The temporary branch is formatted the way it is for a reason, scripts depend and expect it to be this way!

Testing

Make sure Windows, Linux and Mac OSX versions can be created. Test whether the game actually works on these platforms. In both single- and multiplayer!

Have a look at the Testing page for a detailed rundown.

Note: It is recommended you do a make -Cpo update-po to fix the issue of windows releases having the (modified locally) qualifier on releases.

Bump version numbers

The following files need editing to have the correct version.

ChangeLog

Edit the ChangeLog to be in sync with the latest changes. Also make sure to put the correct date and version there (the date that you make the release of course).

configure.ac

Make sure to put the correct version number in the second parameter of AC_INIT. The AC_INIT directive should be somewhere at the top of the file. 

AC_INIT([Warzone 2100],[2.3_beta1],[http://wz2100.net/],[warzone2100])

Make it default to release builds.

# Add later for stricter checking: -Wextra -Wmissing-declarations -Wstrict-prototypes 
AC_ARG_ENABLE([debug], 
AS_HELP_STRING([--enable-debug[=yes/relaxed/profile/debugprofile/no]],[Compile debug version [[yes]]]),
[ enable_debug=${enableval} ], [ enable_debug=yes ])

change it to:

[ enable_debug=${enableval} ], [ enable_debug=no ]) 
...
AC_MSG_CHECKING([whether to compile in debug mode]) 
AC_MSG_RESULT([${enable_debug}])

dpkg changelog

cd pkg/dpkg
./editchangelog -v 9:X.Y.Z

will add a new entry for version X.Y.Z with the correct date and email address. For the text, just the version number should be enough.

autorevision.conf

wc_uri=tags/<tagname>

Here <tagname> should be the name of the branch in Git, for example, 3.0_beta3

win32/warzone2100.rc

Put the correct version number after the FILEVERSION and PRODUCTVERSION directives. This must be four numbers separated by commas, for example, for 2.0.8 this would be: 

FILEVERSION 2,0,8,0
PRODUCTVERSION 2,0,8,0

Then secondly in the version table modify the "FileVersion" and "ProductVersion" values. These are strings (you can use similar syntax as in C to put a string there). For version 2.0.8 this would look like this: 

			VALUE "FileVersion", "2.0.8"
			// ...
			VALUE "ProductVersion", "2.0.8"

lib/framework/config-macosx.h

Modify the PACKAGE_STRING macro to "Warzone 2100 <version>", the PACKAGE_VERSION macro to "<version>" and the VERSION macro to "<version>". E.g. for 2.0.8 this would be: 

#define PACKAGE_STRING "Warzone 2100 2.0.8"
#define PACKAGE_VERSION "2.0.8"
#define VERSION "2.0.8"

lib/netplay/netplay.cpp

  • if the network protocol has changed, do not forget to bump the NETCODE_VERSION_* version(s).
  • the VersionString is used for lobby display only. 
    char VersionString[VersionStringSize] = "2.2";
static int NETCODE_VERSION_MAJOR = 2;                // major netcode version, used for compatibility check
static int NETCODE_VERSION_MINOR = 68;               // minor netcode version, used for compatibility check

Mac Builds

Mac builds are run from the ​wz2100Release.sh script.

Before building the Make DMGs for Release script needs to have the proper sections (un)commented.

  • The "high qual seq" section should be uncommented for stable releases
  • The "low qual seq" should be commented out for special builds

Add new version to the Bug Tracker

Make sure to create a new version in the Bug Tracker so people can submit bug-reports for it.

Sync trunk

Update trunk ChangeLog

Copy the newly created ChangeLog entry over to the trunk's ChangeLog (other branches don't matter, but trunk does). (svn merge helps)

Update trunk Debian ChangeLog

Copy the newly created changelog section over to trunk's Debian changelog. Make sure to keep the correct order of versions though (i.e. the "highest" version number needs to be on top). (svn merge helps)

Create a source tarball

  • Check out the branch.
  • Run "./autogen.sh" on exported sources
  • Run "git commit configure Makefile.in <whichever-files-autogen.sh-creates> -m autogen.sh"
  • Run "git archive --prefix=warzone2100-3.X.Y/ HEAD | tar -x"
  • Run "cd warzone2100-3.X.Y/ ; ./autogen.sh ; cd .." on exported sources
  • Create tarball with "tar --numeric-owner -cjvf warzone2100-3.X.Y.tar.bz2 warzone2100-3.X.Y"
  • Sign the tarball with "gpg --detach warzone2100-3.X.Y.tar.bz2"
  • Copy to sf.net download area.

NOTE: You can do the above or :

  • ./autogen.sh
  • ./configure --with-distributor="wz2100.net"
  • make
  • make dist
  • then you will have a tarball created for you.

Create binary packages

  • Use the just created source tarball to test whether it actually works!
  • Use --with-distributor="wz2100.net" to configure!


Create an NSIS installer

  • The __BUILD_SCRIPT will auto-download all the packages you need.

Installer is easiest created using the __BUILD_SCRIPT via

  • ./__BUILD_SCRIPT --enable-installer --with-distributor="wz2100.net" in win32 directory


Do a crash handler test!

  • Test the installer (windows only) Test the .dmg (mac only)
  • Test the crash handler via the --crash command line option, to make sure it produces a good dump file!
  • You will see a assert() in debug builds, and we do NOT want to release debug builds.
  • If you are testing the crash handler in debug builds, use --noassert to skip it.


Wait

Wait a few days between making the temporary branch and actually tagging and announcing the release publicly, because nearly always some mistakes creep in, and it is troublesome to sort them out after people started installing/downloading broken versions.

By waiting a bit you increase the chances that someone (you, another dev, a quick user, ...) notices your mistakes and you are able to correct them before the actual release.

While waiting, the items on the Testing page should be repeated.

Finalise the Tag

First make sure that you are on the tip of temp branch you have made and that no one has any more commits to make to it. Once that is done make the final tag:

NOTE: Use of the -v option instead of -a is preferred (it requires gpg to be installed), but use of at least -a if -v cannot be used is required. 

git tag -a v3.0_beta2

Where 3.0_beta2 is the name of the tag.
NOTE: Again, the name of the tag matters; be extra certain that the tag starts with a v so it can be distinguished from branches with similar names.

Once the final tag has been made and pushed the temp branch should be deleted.

Wiki: Releases-article and front page

  • Make sure to list the new release in the Releases-article.
  • Update the current stable/testing release on the front page.

Announce the release