Tools needed for releasing:
- Normal tools to build everything from Wesnoth and to fetch the repository head (cmake based assumed for this page!)
po4a(to be able to update the manpages and manual)
docbook-xml-dtd(to generate the manual HTML files)
xdelta1.x (to create the Xdelta files)
rsyncfor upload of tarballs
Tools for other processes:
optipng(only for needed to run
utils/wesnoth-optipng, not for normal releases)
convert, only for needed to run
utils/wesnoth-optipng, not for normal releases)
advdef, only for needed to run
utils/wesnoth-optipng, not for normal releases)
Not strictly release associated though the pot-update part should be done right before every release.
utils/wesnoth-optipngfrom the main directory of the checkout every now and then, requires the packages optipng, imagemagick and advancecomp
- Run a
pot-updateregulary, once shortly before the release, this includes the following steps as of current 1.11.2 time:
Change into the repository directory, pull (and rebase!) # create build folder and cd into it mkdir wesnoth-build && cd wesnoth-build # run cmake and at leastenable the pot-update target cmake ../ -DENABLE_POT_UPDATE_TARGET=TRUE # Recreate the manpages (watch out for errors, they are very frequent!) make update-po4a-man # Recreate the manual make update-po4a-manual # Update all the other pot and po files make pot-update # make sure all files compile make mo-update # get out of the build folder back to the git folder cd ../ # Make sure that no new files were created in doc/, if new manpages/manuals were created, add them git status doc/ # Commit the bunch of updated po files and manpages/manuals git add doc/ po/
(the following commands should be run but are usually forgotten...)
data/tools(runs a check for unresolved references, followed by
wmllintwith appropriate options, followed by a check for unused image and resource files)
data/toolsto indent all content correctly
- Have a look at the pages from the category Review on Release
Creating the tarball, xdelta and checksum
First step of releasing is that you warn the devs via IRC and update the topic accordingly. Afterwards you just do the last steps and create the tarball:
- Make sure to run a pot-update (c.f. above)
- Bump the version in
players_changelog, change the version of both
- Do the following steps to generate the release files:
# Update the git checkout, just to be sure that you have the latest version, git pull --rebase # export the git checkout into a release directory git checkout-index -a -f --prefix=/absolute/path/to/export/root-folder/wesnoth-TAGNUMBER/ # remove folders which were never supposed to be in the release cd /absolute/path/to/export/root-folder/ rm -r wesnoth-TAGNUMBER/resources rm -r wesnoth-TAGNUMBER/website # create the tarball tar cf wesnoth-TAGNUMBER.tar wesnoth-TAGNUMBER # create the xdelta (assumption: the uncompressed aaa (oldversion) exists) xdelta delta wesnoth-aaa.tar wesnoth-bbb.tar wesnoth-aaa.tar-wesnoth-bbb.tar.xdelta # compress the tarball bzip2 -9 wesnoth-TAGNUMBER.tar # create md5sum md5sum wesnoth-TAGNUMBER.tar.bz2 > wesnoth-TAGNUMBER.tar.bz2.md5
The following files should be ready for upload now:
These files now need to be uploaded to files.wesnoth.org (as backup) and to sourceforge.net. Just use rsync via ssh to do so. The exact paths for wesnoth.org might change when the server setup changes. After upload to wesnoth.org it might be faster to just ssh there and upload to sf.net from wesnoth.org.
Upload to wesnoth:
rsync -avP -e ssh FILES email@example.com:WWW/html/files/
Upload to sf.net:
- STREAM: replace with wesnoth for dev releases and wesnoth-1.10 for a stable release of the 1.10 series (change the version number accordingly)
- RELEASENAME: replace with the release name, e.g. wesnoth-1.11.2
- Use your normal sf.net username and password for upload
rsync -avP -e ssh FILES ivanovic,firstname.lastname@example.org:/home/frs/project/w/we/wesnoth/STREAM/RELEASENAME
Build the release for testing
The upload can already be started while the upload is running. The upload of the files might take a long time, so starting it early can be a good option. Before installing make sure that no old leftover files are there. Also remove the old preferences. Thi probably requires running as root for the installed files, user privilegies are enough to remove stuff in
You can just reuse the export folder for building:
# cd into export folder cd /absolute/path/to/export/root-folder/wesnoth-TAGNUMBER/ # create build folder mkdir wesnoth-build && cd wesnoth-build
# cmake command to create a test build with suffix -test cmake . -DBINDIR=/games-bin -DDATAROOTDIR=/games -DENABLE_SERVER=TRUE -DENABLE_CAMPAIGN_SERVER=TRUE \ -DPREFERENCES_DIR=.wesnoth-test -DBINARY_SUFFIX=-test -DDATADIRNAME=wesnoth-test \ -DENABLE_NOTIFICATIONS=TRUE # build LC_ALL=C nice -n 11 make # install su -c "make install"
Now cd somewhere else and test wesnoth-test. Running right from the sources is not enough to be sure that everything works as expected.
Test the build
This at least includes the following:
- Start the editor, check if creating a map is possible
- Start the game and try to connect to the official multiplayer server and to the add-on server
- Start the server, connect to it using the game to see if you can enter the lobby
- Check if in the game each campaign does start
- Check if you can start the in-game help and the credits
- Check if it is possible to create a local game
- Play at least one game/scenario (or droid your side to let the AI play), this can either be a normal campaign scenario or a multiplayer game
If all of those points are working as expected, go on, if not, fix the problems and restart from the very beginning.
If everything does work, tag your release. Just use TAGNUMMER for the tag, no need to add wesnoth- in front.
git tag TAGNUMBER COMMITID_TO_TAG -m "tagged TAGNUMER, using commit COMMITID_TO_TAG" git push --tags
Create an updated macro-reference.html and upload it:
cd /absolute/path/to/export/root-folder/wesnoth-TAGNUMBER/data/tools make macro-reference.html scp macro-reference.html email@example.com:WWW/html/macro-reference.html
Create latest credits and use them to update the website
cd /absolute/path/to/export/root-folder/wesnoth-TAGNUMBER/ data/tools/about_cfg_to_wiki -w /games-bin/wesnoth-test > about.wiki
Open about.wiki in a text editor and paste the content to Credits.
Once all steps above are done and the upload to sourceforge is finished, you still need to notify the packagers. The announcement should include the important changes for packagagers (especially path and requirementchanges) as well as the md5 of the tarball attached, Make sure to sign md5 and mail when sending.
This is the current list of packagers who want to be notified as of 1.11.2:
markus.schmeing |ATTT| udo.edu (unofficial gentoo packages, basically inactive) hhetter |ATTT| novell.com (OpenSuse packager) enqlave |ATTT| gmail.com (unknown) michael |ATTT| sterretts.net (unknown) sobotkap |ATTT| centrum.cz (OpenSolaris) rhonda |ATTT| deb.at (current debian packager) cycholka |ATTT| wp.pl (old Windows packager) amirserdang |ATTT| gmail.com (old Mac OSX packager) ben |ATTT| happyspork.com (old Mac OSX packager) wtogami |ATTT| gmail.com (unknown) alarantalara |ATTT| gmail.com (current Mac OSX packager) dougmencken |ATTT| gmail.com (unknown) lipka.boldizsar |ATTT| gmail.com (unknown)
Basic text for such an announcement:
subject: Wesnoth TAGNUMBER is out! mailtext: Hi, Wesnoth TAGNUMBER is out! :) The sources are already available via sf.net and files.wesnoth.org (just as backup). I will announce the release once the MacOSX and Windows binaries are done and uploaded. The announcement will not happen in the next 24h and if the MacOSX and Windows binaries take "too much time" I will just announce in 72 hours. In the meantime you can create and upload your packages. Some foo about changes/additions/stuff to keep in mind, especially stuff from the RELEASE_NOTES. Best regards and thank you for your contribution to Wesnoth SIGNATURE attachment: wesnoth-TAGNUMBER.tar.bz2.md5
Contact Soliton/Shadowmaster so that he updates the server to support the new version (required for development releases, should not be needed for stable releases after RC time is started)
Cleanup and post release steps
Bump version to
players_changelog and commit the change.
Remove the release related files (export folder, tarball, xdelta, ...).
The real annoucement
Prepare the real announcement forum post for the day it is to be posted. To do so copy the last announcement from the release thread into the moderators forum (edit, then copy&paste). Adjust it to match the new release. And leave it there for fixes and comments until the time for the real announcement comes. Make sure to use the stuff from the RELEASE_NOTES and clean them afterwards.
Wait until the conditions from the mail to the packagers are met (waited at least 24h and OSX and Windows binary are ready OR 72h passed).
Now do the following steps to get the real release out:
- Update the downloads website in the wiki.
- Copy the prepared announcement forum post into the announcement category and post it as 'announcement'.
- Set the previous announcement to a 'normal' post.
- Update the frontpage:
- Change version in header to list the latest version.
- Update the news list and make sure to point to the correct forum post.
- If the news section is getting too long, remove some of the oldest posts.
- Copy the new news to Older_News
- Submit versions updates for stable versions to all sites that are known to monitor Wesnoth, ask the respective packagers to do so for OS specific sites (like apple.com).
Sites monitoring Wesnoth releases
This is a (probably completely outdated) list of sites that monitor Wesnoth releases. Most of these require manual submissions of update request. This should be done by whoever has an account at the respective sites: