ReleasingWesnoth

From The Battle for Wesnoth Wiki
Revision as of 03:02, 8 February 2016 by Shadowm (talk | contribs) (→‎Build the release for testing)

Tools

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)
  • xdelta 1.x (to create the Xdelta files)
  • rsync for upload of tarballs

Tools for other processes:

  • optipng (only for needed to run utils/wesnoth-optipng, not for normal releases)
  • imagemagick (tool convert, only for needed to run utils/wesnoth-optipng, not for normal releases)
  • advancecomp (tool advdef, only for needed to run utils/wesnoth-optipng, not for normal releases)

General maintenance

Not strictly release associated though the pot-update part should be done right before every release.

  • Run utils/wesnoth-optipng from the main directory of the checkout every now and then (read: very rarely, it enlarges the Git repository for very negligible reductions in distribution size), requires the packages optipng, imagemagick and advancecomp
  • Run a pot-update regularly, 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:
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 (replace <N> with number of parallel jobs to run)
make update-po4a-manual -j<N>
# Update all the other pot and po files (replace <N> with number of parallel jobs to run)
make pot-update -j<N>
# 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 commit doc/ po/

(the following commands should be run but are usually forgotten...)

  • Run make lint inside data/tools (runs wmllint with appropriate options), fix warnings or prod campaign and content maintainers as needed
  • Run make reindent from data/tools to 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

Release tasks

Preparation steps

  • 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.
  • Check changelog and players_changelog for completeness and correctness, line wrap to 80 columns.
  • Bump the version numbers in src/wesconfig.h, Doxyfile, changelog, and players_changelog and commit. Note that as of version 1.13.2 there are additional RC_VERSION_* macros in src/wesconfig.h needed by Windows builds. Since unlike VERSION these aren't freeform values, they should represent the next release version whenever VERSION represents an in-dev version (e.g. if VERSION is 1.13.2+dev, the RC_VERSION_* macros should have the values for 1.13.3 instead).

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

File upload

The following files should be ready for upload now:

  • wesnoth-$VERSION.tar.bz2
  • wesnoth-$VERSION.tar.bz2.sha256
  • wesnoth-$OLDVERSION.tar-wesnoth-$VERSION.tar.xdelta

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>,wesnoth@frs.sourceforge.net:/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.

Tagging and extra release related steps

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 wesnoth@wesnoth.org: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.

Notify packagers

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 wesnoth-VERSION+dev in src/wesconfig.h, Doxyfile, changelog and 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 and lock it.
  • 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:

Retrieved from "https://wiki.wesnoth.org/index.php?title=ReleasingWesnoth&oldid=57033"