Latest Posts

Changes in ReleasingWidelands

Editor Comment

Massive changes to release cycle. Hopefully we won't get bitten so often now.


Revision Differences of Revision 7

## 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 mostly 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: ¶

* Agree on a date for release and release candidate on widelands-public ¶
* 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!) ¶
* Find a release manager. ¶
* Feature & Goal check. Check the milestones targeted bugs and blueprints. ¶
* Check, that [ChangeLog](/changelog) is valid. This needs to be done in trunk. ¶
* Check, that DevelopersPage (authors) file is valid. This needs to be done in trunk. ¶
* Merge latest translations into trunk from lp:~sirver/widelands/translations ¶
* Branch from trunk, tag the release in the new branch. ¶
* Apply specific patches for this release. ¶
* Add a proper WL_RELEASE file. ¶
* Mark all bugs that have Fix Committed as Fix Released. Add as comment the name of this build. ¶
* Inform the packagers. ¶
* Use bzr export to export the source package (tar.bz2). Upload the source tarball as early as possible, as some distro packagers need an official source tarball for reference. ¶
* Mark the milestone as a release, upload the packages. ¶
* 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. ¶

* Prepare a release statement for news etc.; use release statements of previous releases as a template. ¶
* Announce the release: ¶
* Allow roughly two days between tagging the build in our Subversion repository before posting news items. ¶
* freshmeat.net (current project owner there is sigra) ¶
* widelands-public & widelands-announce & launchpad news & sf.net news. ¶
* wl.widelands.org homepage ¶
### Step 1: First-Snow Feature Freeze ¶

* Implement or reschedule targeted features for this build. ¶
* Maintenance stuff: ¶
* update developers ¶
* update changelog ¶
* check docs ¶
* merge translations ¶
* Agree on a date for first-snow feature freeze on widelands-public. ¶
* First-Snow feature freeze means: ¶
* no new features ¶
* no style fixes ¶
* no changes to campaigns ¶
* no new tagged strings ¶
* only minimal invasive bug fixes. That is if a bug can be fixed in a ¶
dirty-but-minimal-invasive change and in a correct way, the one that ¶
doesn't touch on any other code should be prefered and the correct way ¶
should go into a feature branch. ¶

Development should not cease but continue in feature branches. No more stuff should go to trunk though. ¶
As soon as all targeted bugs are fixed, we continue with ¶

### Step 2: Winter-Time feature freeze (The Real Feature freeze) ¶

* When all targeted bugs are fixed, a date for winter-time feature freeze is ¶
set. This should be roughly two weeks from the last bug's fixings date. One week ¶
after this the build candidate release is to be scheduled. ¶
* Maintenance stuff: (all of the above) ¶
* Announce the feature freeze date on the homepage to give translators/graphic ¶
arists a chance to catch up. ¶
* This feature freeze extends to **everything**: from translations to media, ¶
code, style. So there is one week where everything should already be perfectly working before the ¶
build candidate just to make sure that no last minute things come up. ¶
* Obviously, new surfacing critical bugs are to be vanquished. Non critical bugs are to be defered to ¶
the next version. What's critical should be discussed on the mailing list if there is no consense. ¶

### Step 3: Build candidate ¶

* On the build candidate day the release does the following: ¶
* Maintenance stuff: (all of the above) ¶
* Branch from trunk, tag the release in the new branch. ¶
* Add a proper WL_RELEASE file. ¶
* Mark all bugs that have Fix Committed as Fix Released. Add as comment the name of this build candidate. ¶
* Tag the build candidate in the build branch ¶
* Disable the milestone. Do not mark it as release yet. ¶
* Use bzr export to export the source package (tar.bz2). Upload the source ¶
tarball so that packagers can use it as reference. ¶
* Upload the source package for packagers to find. ¶
* Inform the packagers. ¶
* Add a new milestone for the final build ¶
* As soon as Windows, Mac and Linux binaries are available: ¶
* Mark the milestone as a release, upload the packages. ¶
* Add a post on the homepage. ¶

Approximately one week after the release candidate, the final release should follow: ¶

### Step 4: Releasing ¶

* Fix a date for releas on widelands public. ¶
* On the date: ¶
* Merge trunk into the build branch ¶
* Update the WL_RELEASE file. ¶
* Mark all bugs that have Fix Committed as Fix Released. Add as comment the name of this build. ¶
* Tag the build in the build branch ¶
* Use bzr export to export the source package (tar.bz2). Upload the source ¶
tarball so that packagers can use it as reference. ¶
* Upload the source package for packagers to find. ¶
* Inform the packagers. ¶
* As soon as Windows, Mac and Linux binaries are available: ¶
* Prepare a release statement for news etc.; use release statements of previous releases as a template. ¶
* Mark the milestone as a release, upload the packages. ¶
* Send a Mail to widelands-announce with the release-statement ¶
* Send a Mail to widelands-announce with the release-statement ¶
* Announce on launchpad with the release-statement and full changelog ¶
* Add a post on the homepage. ¶

### Step 5: Post Release ¶

* Post-Release Mail to widelands-public: ¶
* Discuss problems with this release. Update this checklist with good changes accordingly. ¶
* Lift feature freeze from trunk. ¶
* Encourage people to update infos about widelands on the web: wikipedia, freshmeat, linuxgametome ¶
and more. ¶

* Send cap-over-the-mill Mail to widelands-public about the next build ¶
* State organisatorial plans ¶
* State project driver vision plans ¶
* State plans as a developr ¶
* encourage other developers to post replys and their own plans.

### Creating binary packages ¶

#### Windows ¶

For compilation of widelands-binary take a look at BuildingWidelandsUnderWindows and the README-file in [widelands-trunk]/build/win32 ¶

Compilation of a Setup-file is done via /build/win32/innosetup/Widelands.iss Script, which can be run with [Inno Setup](http://jrsoftware.org) -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 UsingTheSconsBuildSystem, 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: ¶

* Extract the release source package. ¶
* Build the widelands executable using SCons, but see the points above. ¶
* Perform some basic test (e.g. that translations are found). ¶
* Delete everything that is only relevant for source packages.# 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 ¶

* Delete SConscript files in subdirectories. ¶

* Create the tarball. ¶
* 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? ¶
* 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 ¶