Table of Contents
- Release Process Break-Down
- Release Branching
- Test the tutorials
- Organize a first staff match
- Prepare for branching
- Create a release-aXX branch
- Adapt Jenkins for the release
- Prepare next multiplayer lobby in main
- Generate next signing key for mods in main
- Start writing release announcement
- Start creating the release video
- String Freeze
- Commit Freeze
- Full Freeze - Release Testing
- Release
Release Process Break-Down
Release Branching
After preparative checks, a release branch is created, and nightly builds and translation updates start following it. We start generating daily release candidates from the nightly builds. The next development cycle can start on the main branch. A Release Manager is desginated, only they can push to the release branch. It is forbidden to publish a fix in the release branch that is not a cherry-pick of a fix in main.
Test the tutorials
Candidates: Everyone
We must check the tutorials that are accessible from the main menu work and take into account the changes from the development cycle.
Organize a first staff match
Candidates: Anyone
A staff game session should be organized before the release. Often important bugs get discovered in such staff matches. Organizing the match means finding a good date and time and informing the other team members (or community members). All players must use a clean nightly build.
Prepare for branching
Candidates: Everyone
- Ensure Alpha name and number have been updated in BuildLabel.xml, ProjectInformation.js, mod.json, and build_version.h.
- Remove the "new" keyword from all maps of prior releases and add it to the maps of the current release.
- Ensure the MUC room for the lobby in
default.cfgis set to the current release.
Create a release-aXX branch
Candidate: Release Manager
Create a release branch in the format release-a27. Restrict pushing to this branch to the Release Manager.
Adapt Jenkins for the release
Candidates: Itms
Update the Jenkins configuration for the nightly build, so that it follows the release branch instead of the main branch. Update the configuration for the bundles build, so that it builds daily after the nightly generation. See also JenkinsSetup.
Prepare next multiplayer lobby in main
Candidates: Dunedan, user1
We can create a new lobby for the next development cycle, and update default.cfg on the main branch. This allows development of the lobby features to continue while features are freezed for the upcoming release.
- Create a new MUC room for release+1
- Set up bots and empty ratings database for release+1 according to https://github.com/0ad/lobby-infrastructure/
- Set the existing lobby moderators as room administrators for release+1
- Commit config changes to the
mainbranch
Generate next signing key for mods in main
Candidates: Stan, Itms
The valid mods for the next version should be signed with a new key, and the associated public key must be put in the config for the next version. It is recommended to sign official mods (community balance, CJK, ...) with the new key at the same time, so that the mod downloader can be tested at any moment in the development process. To generate the keypair use minisign -G -p pubkey -s secretkey. Do not override the old keys.
Start writing release announcement
Candidates: Everyone
- Write a release announcement that will be published on the website and other places like Moddb.
- Describe new features, content and major bugfixes. If necessary ask people to provide descriptions.
- Create one or more unique screenshots that fit well for this Alpha release (or find someone to create these).
- Write a short description of the Alpha name and the reasons why we have chosen this name (historical term around the timeframe of 0 A.D.).
Start creating the release video
Candidates: Brynn, Stan, Vlad
An Alpha release video showcases the new features, content and major bugfixes of this version. It focuses more on the features that can be shown well in a video. Remember to upload the video on the play0ad youtube channel.
String Freeze
When the remaining fixes to be implemented are guaranteed not to touch the user-facing text, we publish an announcement for translators, and we strictly stop introducing any string changes in the release branch. A Translations Officer is nominated to assess the quality of translations during the release process. The rest of the team focuses on fixing bugs and preparing announcements.
Announce string freeze
Candidates: Stan
Translators should be informed about the String Freeze and the planned Full Freeze date (at least 10 days from now). The idea is to give them some time to polish the final translations for the release.
Long strings check
Candidates: Translations Officer
Using the debug "long" locale, go through as much parts of the GUI as possible, and see if some parts should and can be tweaked without changing the strings themselves. In case the fix needs to break String Freeze, fix only in main and/or create a ticket for the next release.
Commit Freeze
When all the fixes are in, we stop committing to the release branch, except for the listed exceptions below. The nightly builds continue to be generated every day with the newest translations.
Translation check
Candidates: Translations Officer
TODO: This should be done as part of CD throughout the entire development process.
Daily check the translations for "vandalism" and syntax breakage.
- Against vandalism, it's really just checking if there are any strings that were added in bad intent and not about trying to improve translation quality. There's a script to check the translation files for URLs ([checkTranslations.py]source:ps/trunk/source/tools/i18n/checkTranslations.py), but this task also involves manual checking. Obviously we can't carefully read through all strings in all translations.
- Syntax errors can happen when translators incorrectly copy
sprintfcalls and special GUI tags. Most of the errors are detected by Transifex, but sometimes translators ignore the warnings. So we have [lint-translations.sh]source:ps/trunk/build/jenkins/lint-translations.sh which detects broken sprintf calls, but it doesn't detect broken GUI tags. So manual checking is still necessary.
Decide on included translations
Candidates: Translations Officer
Depending on the completion status of translations, and their apparent quality, the Translations Officer is allowed to commit changes to source/tools/dist/remove-incomplete-translations.sh. The version of that file in the main branch should serve as a list of first-class languages we aim to support for each release in order to reach as many players as we reasonalbly can worldwide. The version in the release branch can be extended on a case-by-case basis, for each release. The Translations Officer can amend this file as many times as needed up until the full freeze. Make sure the list of Windows installer languages is always updated accordingly.
Organize another staff match
Candidates: Anyone
If all the tasks have been completed and we still have time before the announced Full Freeze, do another celebration staff match.
Full Freeze - Release Testing
If :
- At least 10 days have passed since the string freeze announcement
- Only the meta task for the release remains in the Milestone
- All checkboxes are ticked up to the "Full Freeze" separation in the meta task
then, we stop the nightly builds. The official release candidate is generated from the latest nightly build, and published on https://releases.wildfiregames.com/rc. If an issue is found, we fix it and go back to Commit Freeze. If an issue is found that requires changing user-facing text, we fix it and go back to String Freeze.
Freeze Jenkins
Candidates: Itms
Deactivate the nightly-build job on Jenkins, and stop the scheduled builds for bundles. Upload the latest generated bundles to https://releases.wildfiregames.com/rc, generate their hashes, and sign them. If this is not the first RC, do not overwrite old RCs until the release happens.
Confirm full freeze
Candidates: Stan
Translators should be informed of the full freeze and that their changes will stop going into the release. Ask them to make sure their changes are indeed in the nightly builds and point them to the RC download page. Keep an eye on bug reports from them which may warrant a thaw.
Package East Asian mods
Candidates: Anyone
- Get the latest version of Source Han Sans fonts for CJK languages.
- For each East Asian language complete enough, select the font subset for the language under the SubsetOTF directory. The interesting fonts should be Normal size for most of our fonts and Medium size for the two bold ones.
- Follow the steps from Adding_font_support in order to render the fonts. Don't do the font caching already.
- Create a mod for each language, containing a
mod.json, afonts/folder in which to place the rendered fonts and the licence text files, and al10nfolder. Place the .po files for the language in the latter. - Use the following command to build an archive for each mod (here is the example for ja):
./pyrogenesis -mod=mod -archivebuild-compress -archivebuild=/path/to/0ad/binaries/data/mods/ja-lang-0.0.XXX -archivebuild-output=/path/to/0ad/binaries/data/mods/ja-lang-0.0.XXX/ja-lang-0.0.XXX.zip - Generate a signature for checking the files when downloaded from mod.io (or from anywhere if people are careful):
minisign -SHm ja-lang-0.0.XXX.zip -s private-key - Upload the file to mod.io and update the signature in the
minisigsarray in the metadata field. - Upload the file to https://releases.wildfiregames.com/rc.
Announce Release Candidates
Candidates: Anyone
Announce the RC on the forums and gather as many test feedback as possible. Decide on thawing the Full Freeze depending on found issues.
Release
If the latest RC seems to work as expected, we promote it to release. We publish release announcements, notify the maintainers of the game and the regular reporters.
Tag the release commit
Candidates: Release Manager
Tag the tip of the release branch, making sure this commit is indeed the one from which the good RCs were generated (the 5-char commit hash is displayed in the main menu). Push that tag to Gitea. Publish the associated release in the Gitea repo.
Create torrents and checksum files
Candidates: Itms, Stan, wraitii
On releases.wildfiregames.com:
- Move the good RCs from
www/rc/towww/, and delete the others - Run
./updateon the server
Upload to Sourceforge and IndieDB
Candidates: feneur, Itms
After all packages are created and tested, they can be uploaded to sourceforge.
rsync -v --progress -e ssh 0ad-0.0.N-*.{exe,gz,xz,dmg} username,zero-ad@frs.sourceforge.net:/home/frs/project/z/ze/zero-ad/releases/
rsync -v --progress -e ssh locales/*0.0.22.zip username,zero-ad@frs.sourceforge.net:/home/frs/project/z/ze/zero-ad/releases/locales/
They can also be uploaded to IndieDB & Itch.io for yet another download platform. Create a new file at https://www.indiedb.com/games/0-ad/downloads/add/ for Windows and macOS. Use the "upload by URL" system if you don't want to download the whole file locally.
Don't forget to login there and update the latest release as it is not done automatically.
Move the lobby
Candidates: Dunedan, user1
- Migrate ratings from the release-1 room to release room
- Disable the ratings bot for the release-1 room
- Transfer the list of outlasted JIDs from the release-1 room to the release room
- Change the topic of the release-1 MUC room to notify users that a new version is available
Publish announcement
Candidates: feneur, Stan, Jeru
- Official website http://play0ad.com
- Forum
- Update Alpha version on official website (Settings > General > Tagline)
- Update download pages on official website (http://play0ad.com/download/mac, http://play0ad.com/download/win, http://play0ad.com/download/source)
- Official social media platforms (Facebook, Twitter, Mastodon.)
- ModDB/IndieDB
- Itch.io
- E-mail regular bloggers/reporters
- Mastodon
Notify packagers
Candidates: Release Manager
- Arch 0ad 0ad-data - Flag Package Out of Date
- Debian - email Ludovic Rousseau
- Fedora - email pcpa (see owner)
- FreeBSD - email madpilot@ (See https://www.freebsd.org/cgi/ports.cgi?query=0ad)
- Gentoo - email the Gentoo Games Project (see https://packages.gentoo.org/packages/games-strategy/0ad Maintainer)
- Mageia - email akien@ and/or fwang@ (See http://pkgsubmit.mageia.org/data/maintdb.txt, http://svnweb.mageia.org/packages/cauldron/0ad/current/)
- OpenBSD - email ???
- OpenSUSE - email dimstar@
- Slackware - (See https://slackbuilds.org/repository/14.2/games/0ad/)
- Ubuntu (PPA) - ping ricotz on IRC
- Ubuntu (Snap Store) - ping oSoMoN on the forums; Itms and Stan have access to the snapcraft.io page.
Post-Release
Candidates: Release Manager
After a couple days have passed, cleanup the release:
- Delete the release branch (its tip is tagged)
- In Jenkins, re-target the nightly-build job to the main branch and re-enable it
- Consider regenerating the nightly repo from scratch to save server space
- In Jenkins, reset the bundle generation schedule to bi-weekly
- In Gitea, check the final box in the meta issue and close it
- In Gitea, set the milestone date to the release date and close it
- ??
- Profit