Releasing widelands

Releasing new versions of widelands

This document is about what steps are to perform to release a new build of widelands.

We release one release candidate before each release, to make sure no completely stupid mistakes creep into a release. The steps for preparing the RC are exactly the same as the steps for preparing the final release, to ensure that problems with the release problems are found with the release candidate.

Release cycle

The rough release cycle should work like this:

1. Agree on a date for release and release candidate on widelands-public
2. Find a release manager.
3. Feature & Goal check
   1. Updating the Roadmap and checking, if all goals are reached.
   2. Check, that Changelog is valid (Check with wiki page)
   3. Check, that Developers(authors) file is valid (Check with wiki page)
4. Check for rare maintenance tasks
   1. Optimize PNG files

1. On the agreed-upon date, release the release candidate.
2. From that point on, only bugfixes and translation/documentation updates are allowed into trunk (trivial changes to image and sound data might be allowed, but be careful!)
3. Approximately one week after the release candidate, release the final build.

Releasing a build

As noted above, the steps for RC and final build should be the same, to flush out any problems with the process.

1. Tag the build in our Subversion repository, using the remote svn cp command.
2. In the tagged version of the build ([b]not[/b] in trunk), add build-specific patches
   1. Change SConstruct to default to 'release' and 'build-NN[rc]' as BUILD_ID

1. Prepare a release statement for news etc.; use release statements of previous releases as a template.
2. On SF.net, create a new release build-NN[rc] under the widelands package.
3. Export (using svn export) into a new directory called widelands, create a source tarball widelands-build-NN[rc].tar.bz2 from the unmodified directory.
4. Create binary packages for as many platforms as possible. Developers who are not the release manager are expected to contribute.
5. Upload all packages (source and binary) to the SF.net release, as they get packaged.
   1. Upload the source tarball as early as possible, as some distro packagers need an official source tarball for reference.

1. Allow roughly two days between tagging the build in our Subversion repository before posting news items.
2. Post news to:
   1. SF.net project news
   2. freshmeat.net (current project owner there is sigra)
   3. Remember to send the email alert in File Release management on SF.net to people who are watching the widelands package
   4. widelands-public & widelands-announce
   5. www.widelands.org homepage
3. Add group to tracker.

Creating binary packages

Windows

For compilation of widelands-binary take a look at Building Widelands under Windows and the README-file in [widelands-trunk]/build/win32

Compilation of a Setup-file is done via [widelands-trunk]/build/win32/innosetup/Widelands.iss Script, which can be run with Inno Setup-Compiler.

Linux (directory independent)

These points are intended to help in creating a tarball that can easily be extracted and run in-place (e.g. in a user's home directory). For general Linux build info, see Using the SCons build system, among others.

Here are some things you need to be aware of:

• The locale directory must be correct; otherwise, Widelands will not find translations. Adding the parameters install_prefix=. bindir=. datadir=. localedir=./locale to the scons command line should work, but be sure to test the binary package before the actual release.
• Some Linux distributions still don't have GLIBC 2.4 (i.e. Debian Etch). To support them, hack build/scons-tools/scons_configure.py and replace the compile flag -fstack-protector-all by -fno-stack-protector. You can check for GLIBC dependencies on the final executable using strings widelands | grep GLIBC.

These are the suggested steps for building the package:

1. Extract the release source package.
2. Build the widelands executable using SCons, but see the points above.
3. Perform some basic test (e.g. that translations are found).
4. Delete everything that is only relevant for source packages.
   1. The following should be an exhaustive list of the files and subdirectories in the main Widelands directory:
      • campaigns
      • ChangeLog
      • COPYING
      • CREDITS
      • fonts
      • locale
      • maps
      • music
      • pics
      • sound
      • tribes
      • txts
      • widelands
      • worlds
   2. Delete SConscript files in subdirectories.
5. Create the tarball.
6. Extract the tarball into a new directory and perform some basic tests before uploading.

Other

TODO: This section should contain (or point to) documentation concerning how to build binary packages for different platforms:

• Linux, installable (i.e. .deb/.rpm packages that are integrated into the FHS hierarchy)
• Mac OS X
• others?

1. Delete all source releveant stuff; the remaining files in the main Widelands directory should be: campaigns ChangeLog COPYING CREDITS fonts locale maps music pics sound tribes txts widelands worlds