- 1 Version numbering
- 2 Tools
- 3 General maintenance
- 4 Release tasks
- 5 File upload
- 6 Build the release for testing
- 7 Test the build
- 8 Tagging and extra release related steps
- 9 Notify packagers
- 10 Cleanup and post release steps
- 11 The real announcement
We use the even/odd minor number convention. A.B.C where B is even means stable and B is odd means unstable/development version.
1.15.x are development versions for 1.16.0.
A development version should be called "beta 1" when no further API changes are expected, nor string changes. At that point, translators and add-on authors can start working on 1.15.x without worrying that the rug be swept under their feet.
A development version should be called "release candidate 1" when all blockers have been fixed.
During the beta/RC/stable stages, no API changes (e.g., Lua/WML interfaces or semantics) should be made , nor large-scale or destabilizing internal changes, nor build dependencies changed. That's true from "1.15.x (1.16 beta 1)" and for the rest of the 1.16.x releases too. Such changes should be made in 1.17.x for 1.18.
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 (read: very rarely, because it enlarges the Git repository for very negligible reductions in distribution size), requires the packages optipng, imagemagick and advancecomp
- Run a
pot-updateregularly, once shortly before the release and before each string-freeze (including string-freezes in preparation for stable releases). This involves the following steps as of 1.13.3:
# target "pot-update" regenerates pot files and updates po files according to them # target "update-po4a" reruns po4a for man pages and manual # target "manual" regenerates manual scons pot-update update-po4a manual # 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 commit doc/ po/
(the following commands should be run but are usually forgotten...)
wmllintwith appropriate options), fix warnings or prod campaign and content maintainers as needed
data/toolsto reindent all mainline WML according to our conventions (probably don't want to do this too often as it may inconvenience coders)
- Have a look at the pages from the category Review on Release
- If it's a 1.foo.0 release, start a new campaignd instance on add-ons.wesnoth.org and update the port numbers as in https://github.com/wesnoth/wesnoth/commit/211f14176ce57509003ca4542d388c526157093c
- Announce to developers the string freeze start date (deadline for string changes) and the release cutoff date (deadline for commits)
- Merge the fixes on SpellingMistakes
- Review issues in the relevant labels (probably these? Blocker, Regression, Urgent, and either Fwdport or Backport depending on what branch you're releasing) and milestones (for example, 1.15.2 and 1.16.0, if a development release; just 1.14.9, if a stable release).
- For 1.15.3, review the pre-1.16.0 string freeze issues
- Review the list of issues for the previous patch release (1.15.1 or 1.14.8), make sure it's empty.
- Make sure to run and commit a pot-update (see above), and update to the latest revision of the branch if needed. At this point you should warn people to stop pushing commits to the branch you'll be using for the release so as to avoid last-minute work sync issues or new unexpected bugs.
players_changelogfor completeness and correctness, line wrap to 80 columns.
- Bump the version numbers in
projectfiles/Xcode/Info.plistand commit. Note that as of version 1.13.2 there are additional
src/wesconfig.hneeded by Windows builds. Since unlike
VERSIONthese aren't freeform values, they should represent the next release version whenever
VERSIONrepresents an in-dev version (e.g. if
RC_VERSION_*macros should have the values for
Generating the 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 tar archive (substitute # $VERSION with the release version number and $BRANCH with the # source branch). This will automatically exclude unwanted # directories from the archive following export-ignore rules in # .gitattributes git archive --format=tar --prefix="wesnoth-$VERSION/" $BRANCH > "wesnoth-$VERSION.tar" # Create the xdelta patch for the archives (this assumes that the # uncompressed $OLDVERSION tar archive is present!) xdelta delta wesnoth-$OLDVERSION.tar wesnoth-$VERSION.tar wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta # Compress the tarball bzip2 wesnoth-$VERSION.tar # Create the SHA256 sum for the tarball sha256sum wesnoth-$VERSION.tar.bz2 > wesnoth-$VERSION.tar.bz2.sha256
The following files should be ready for upload now:
You must upload these files to SourceForge.net and to
files.wesnoth.org/releases/ (as backup). Since the tarballs are very large it's recommended to use rsync via SSH instead of web uploads to guarantee their integrity. After uploading to wesnoth.org it might save time to rsync to SF.net from there.
For uploading to wesnoth.org, you will need to ask the site administrators for help with setting up your SSH configuration, as well as determining the destination path for the files.
# Upload to files.wesnoth.org (path for reference purposes only, # does not reflect actual server set-up). rsync -avP -e ssh <FILES> <USERNAME>@wesnoth.org:WWW/html/files/ # Upload to SF.net: # # * STREAM: replace with 'wesnoth' for development releases and # 'wesnoth-X.Y' for a stable release of the X.Y series. # * RELEASENAME: replace with the release name, e.g. # 'wesnoth-X.Y.Z'. rsync -avP -e ssh <FILES> <USERNAME>,email@example.com:/home/frs/project/w/we/wesnoth/<STREAM>/<RELEASENAME>
Build the release for testing
You can build the release for testing while the upload is in progress. Before installing the test build make sure that no old leftover files are there, and also remove the old preferences or (preferably) use the
utils/wesnoth-defaults script found in the repository to use a throwaway preferences dir.
# Depending on whether you already compressed the tarball or not tar -xvf wesnoth-$VERSION.tar tar -xvf wesnoth-$VERSION.tar.bz2 cd wesnoth-$VERSION && mkdir build && cd build # CMake command to create a test build with suffix -X.Y.Z to be # installed to /opt/wesnoth-X.Y.Z instead of /usr/local cmake .. \ -DCMAKE_INSTALL_PREFIX=/opt/wesnoth-X.Y.Z \ -DENABLE_SERVER=TRUE \ -DENABLE_CAMPAIGN_SERVER=TRUE \ -DPREFERENCES_DIR=.wesnoth-X.Y.Z \ -DBINARY_SUFFIX=-X.Y.Z \ -DENABLE_NOTIFICATIONS=TRUE \ -DENABLE_STRICT_COMPILATION=TRUE # Build make -j<N> # install sudo make install
Now cd somewhere else and run the installed copy of the game (e.g.
/opt/wesnoth-X.Y.Z/bin/wesnoth). 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 works as expected, tag your release. Just use the version number (e.g.
1.14.0) for the tag, no need to add
wesnoth- in front:
git tag -a -m "Wesnoth $VERSION" $VERSION HEAD && git push $VERSION
cd data/tools/ make macro-reference.html scp macro-reference.html firstname.lastname@example.org:WWW/html/macro-reference.html
Regenerate the game credits and paste the contents to Credits on the wiki:
data/tools/about_cfg_to_wiki -w <PATH TO GAME EXECUTABLE> > about.wiki
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 packagers (especially path, dependencies, and other build-time changes), as well as the SHA256 checksum of the tarball attached.
For the current list of packagers, check
/scratch/packagers-list on the files.wesnoth.org filesystem.
NOTE: Make sure that our "tier 1" packagers (currently Windows and OS X) whose content is hosted by us on SF.net upload the SHA256 sums of their files to files.wesnoth.org/releases/ as well!
TODO: Upload not just the sha256 files but also the actual files, as a backup in case sf.net is down etc
Subject: Wesnoth X.Y.Z is out! Hello, Wesnoth X.Y.Z, a new feature release in the X.Y.x development series, is out now. The sources are already available on SourceForge.net, and files.wesnoth.org (for backup or in case you don't trust the authenticity of the files on SF.net). We will announce the release within the next 72 hours. In the meantime you can create and upload your packages. Nothing has changed for packagers in terms of dependencies or install locations in this release. Thank you for your contribution to Wesnoth!
Subject: Wesnoth X.Y.Z is out! Hello, Wesnoth X.Y.Z, a new maintenance release in the X.Y.x stable series, is out now. The sources are already available on SourceForge.net, and files.wesnoth.org (for backup or in case you don't trust the authenticity of the files on SF.net). We will announce the release within the next 72 hours. In the meantime you can create and upload your packages. As this is a stable maintenance release, nothing has changed for packagers in terms of dependencies or install locations. Thank you for your contribution to Wesnoth!
Cleanup and post release steps
Bump the version numbers in the files mentioned above in the release preparation steps and commit your changes. Consider deleting the test build, tarball, xdelta, etc. from your filesystem as needed.
Contact shadowm or Soliton to update the MP servers' configuration to allow users of the new release or rebuild the servers as needed (only required for development releases).
The real announcement
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 hidden forum (edit, then copy & paste). Edit the new copy to match the new release as needed, and leave it there for fixes and comments until the time for the real announcement comes. Make sure to use the items from
RELEASE_NOTES (which you will purge after the final announcement is published).
You should also prepare the front page/News forum post in advance.
Wait until the announcement conditions are met (waited at least 24 hours and OS X and Windows builds are ready OR 72 hours passed).
When ready to make the announcement public, do the following:
- Update Download in the wiki (currently takes the relevant contents from Template:StableDownload and Template:DevDownload).
- Post the contents of the new announcement post to the Release forum section as a new 'Announcement' topic.
- Set the previous announcement to a 'Normal' topic and lock it.
- Post the new News forum post to the News forum section.
- Update the wesnoth.org front page (yes, this has to be done by hand, I know, it sucks ― shadowm):
- Change versions, sizes, and links in the overview section to point to the latest version.
- Update the front page news section with an HTML version of the News forum post.
- If the front page news section is getting too large, remove some of the oldest posts.
- Copy the new news to Older_News.
- Update topics on IRC and post to social media (Twitter, etc.) as applicable.
- Clean up
RELEASE_NOTESin the repository so it only contains the template for the next release.