Releasing Minetest

Checklist

- Feature freeze
  - [ ] Announced
  - [ ] Release candidate advertised
  - [ ] Weblate sources regenerated and strings frozen
- Pre-release (day of release)
  - [ ] Autogenerate files
  - [ ] Correct source strings on weblate (`LANG_CODE`, `needs_fallback_font`)
  - [ ] Update translations from Weblate
  - [ ] Update changelog
  - [ ] If not a patch release: ensure that PROTOCOL_VERSION has been increased since the last release
  - [ ] If formspec features have been added: ensure LATEST_FORMSPEC_VERSION has been increased since the last release
- Release
  - [ ] Run bump_version and verify
  - [ ] Push new tag
  - [ ] Build and upload Windows version
  - [ ] Build and upload Android version
  - [ ] Create forum topic
  - [ ] Notify ruben to announce on twitter etc
  - [ ] Notify downstream maintainers

Feature Freeze

Announce a feature freeze

Usually, a feature freeze for one week is announced in #minetest-dev. New features aren't accepted in this time and people focus on finding and fixing bugs. To find high priority issues faster, consider linking a release candidate binary to get more test results (for master: GitLab pipeline). This release candidate is usually also posted on the forums (News section).

The feature freeze and release date is set by core developers.

Autogenerate files

Ensure that the language setting enum values contain en: there is no "en" directory, but Minetest supports it. Autogenerate config file examples such as minetest.conf.example (see bottom of builtin/mainmenu/dlg_settings_advanced.lua), etc.

Also update translation templates (both engine and any default games). Note that before you regenerate translations, you most likely want to import existing changes first.

Look into the util sub-directory for tools like updatepo.sh.

Update source strings on Weblate

Make sure that the source strings on hosted.weblate.org are up-to-date. Please also notify translators so they can start working.

Do not just blindly run the scripts without checking. Check if the source strings on Weblate were actually updated. A simple way to check is to look at any translation that was at 100% (on Weblate) before the update. After the update, the percentage should drop because of new strings. If it didn't drop but you know there are new strings in Minetest, this means the update failed.

Before releasing

Verify special translation strings

The translation files contain some special strings: LANG_CODE and needs_fallback_font (see Translating). Verify that all *.po files have a valid value for these strings because translators frequently misunderstand them and enter an invalid value. Fix any invalid values on Weblate by either entering the correct one or by removing the bad translation.

Update translations from Weblate

How to do this -> Translating#How_to_merge_translations_from_Hosted_Weblate

If doing a backported release, you can use the following command to cherry-pick all translation commits from weblate:

git log --reverse --pretty=format:"%h" $BASE..weblate/master -- po | xargs -L1 git cherry-pick

BASE is the commit on master to start from when looking for translation commits. This commit should be newer than the last translation commit on the backport-X branch.

Update changelog

Changelog can be found here.

Ensure protocol version codes have been bumped

If not a patch release: ensure that PROTOCOL_VERSION has been increased since the last release.

If formspec features have been added: ensure LATEST_FORMSPEC_VERSION has been increased since the last release.

The process

This is mostly done by several core developers.

Update version in source

• Define a new version number by running util/bump_version.sh. Verify that this script correctly.
  • changes TRUE to FALSE for the line set(DEVELOPMENT_BUILD TRUE) in CMakeLists.txt
  • updates the version number and release date in misc/net.minetest.minetest.appdata.xml
  • increments versionCode in build/android/build.gradle
  • and commits.
• Tag the version in local git (the script does this) to allow the cmake versioning script to remove the git hash from the version. Do not push the tag to GitHub yet.
• Build, get newest minetest_game, run and check if the thing seems to be working.

Build Windows version

• These are built for 32-bit and 64-bit using either Visual Studio or MinGW. (sfan5 typically provides MinGW builds)
• If at all possible, debug builds (for both MSVC and MinGW) should be produced along with the regular release builds.
• As of April 2018, this GitLab pipeline can alternatively provide win32/64 packages: https://gitlab.com/minetest/minetest/pipelines
  • Since 5.0, the 64-bit builds are compiled with GC64-enabled LuaJIT (to avoid #2988), the GitLab builds are not!

Make sure that the Windows builds work before continuing to do anything!!

Tweak Windows package a bit

• Include Minetest Game and other subgames that were decided on before the release.
• As of 0.4.12, if an MSVC Windows build is made, a .pdb file is also generated. Each such file must be be provided and clearly associated with its respective build.
• Generally, Those making official builds probably already know what they are doing.

Upload Windows package to somewhere

• Windows packages are hosted at GitHub: https://github.com/minetest/minetest/releases

Update branches and tags of minetest and minetest_game on GitHub

• Tag the master branch same as in previous releases: eg. name it "5.0.0".
• The new release should be merged to the stable-5 branch on both minetest and minetest_game. Its important to merge, and not just rebase, so that git describe works.

The problem on the stable-5 branch

Usually, merging releases onto the stable branch just consists of adding the commits to the branch, as it contains direct ancestors of master commits, and git can do a fast forward. During release/freeze of 5.0.1 (both minetest and minetest_game), the anchestor rule has been broken.

Therefore, you'll generate merge commits, but this shouldn't be a problem. In the case of merge conflicts, ensure that the changes on stable-5 are all discarded in favour of the tagged commit at master, by doing a merge commit like:

   git checkout version-tag
   git merge -s ours origin/stable-5
   git push origin HEAD:stable-5

Update Launchpad stable build to get Ubuntu builds for the new version

celeron55, rubenwardy, est31, and ShadowNinja have access.

Process:

• Go to minetest-c55/upstream and minetest-c55/upstream_game and click "start import".
• First, find out the commit hashes of the minetest and minetest_game git repos corresponding to the release.
• Now visit the recipe.
• At the bottom of the page there is a section called "Recipe contents". In this section you need to edit the recipe. Make sure you update:
  • The version number at the end of the first line. Doing this is a must otherwise there would be duplicate packages which would lead to a fail. The version number has a format like 5.1.1-ppa0. You should keep the ppa postfix so that it's easy to differentiate the package by origin, ppa or upstream Debian.
  • The commit hash of the main minetest repo in the second line.
  • The commit hash of the minetest_game repo in the last line.
• Check whether everything has been updated correctly.
• Click the green "Request builds" link, enable the newer distro versions, and click confirm.

The build has two steps: first it assembles the source code and uploads it, then it builds the code. If the first step completed successfully but the second one failed, you need to update the version number in the recipe (e.g. 1.2.3-ppa1) before rebuilding.

Build and Publish Android APK

Notify the Android maintainers to update their APKs for their corresponding platforms:

• nerzhul or rubenwardy (@ chat.freenode.net) for google play. He also holds the signature keys for the play app.
• est31 (@ chat.freenode.net) for f-droid. As f-droid signs its apps itself, the release can be done without him. Best way if est31 is unavailable is to ask on freenode channel #fdroid for help. If that does not help, mention them on GitHub or check the Mozilla IRC network.

Building and signing APKs for the Play Store

• Sign the package: jarsigner -verbose -digestalg SHA1 -sigalg MD5withRSA -keystore keystore-minetest.jks bin/Minetest-release-unsigned.apk Minetest
• Zipalign the apk: zipalign -v 4 bin/Minetest-release-unsigned.apk Minetest-release.apk

Script:

       #!/bin/bash
       
       BUILD_TOOLS=~/Android/Sdk/build-tools/29.0.3
       OUT=app/build/outputs/apk/release
       
       sign() {
               jarsigner -verbose -digestalg SHA1 -sigalg MD5withRSA -keystore keystore-minetest.jks $OUT/$1-unsigned.apk Minetest
               $BUILD_TOOLS/zipalign -v 4 $OUT/$1-unsigned.apk $1.apk
       }
       
       sign "app-arm64-v8a-release"
       sign "app-armeabi-v7a-release"

After releasing

Reenable -dev version suffix

Check that the util/bump_version.sh script did the following steps:

• Update the version number in CMakeLists.txt and the titles of doc/client_lua_api.txt and doc/menu_lua_api.txt
• Change FALSE to TRUE for the line set(DEVELOPMENT_BUILD FALSE) in CMakeLists.txt. This will add the -dev suffix to the version name again.
• Commit.

Write a release notice

• Don't forget to edit the minetest.net page.
• Post a new topic in the News section of the forum. See Changelog.
• Announce the release on the Twitter account. rubenwardy has access.

Notify known package maintainers

• emptty (@ chat.freenode.net; Martin Quinson) maintains Debian packages.
• For Gentoo, one should mail proxy-maint@gentoo.org or talk on the #gentoo-proxy-maint channel on freenode (Zeitgeist_/damiel has resigned as proxy maintainer).
• nerzhul (@ chat.freenode.net) maintains the FreeBSD port and uploads new releases to the Google/Android Play Store.
• neoascetic (mail address on his GitHub profile page) maintains Minetest in the OS X Homebrew repository.
• Akien (@ chat.freenode.net) maintains the minetest package in Mageia.
• sofar (@ chat.freenode.net) maintains the packages for Clear Linux (Intel's Linux distribution).

Add new version to Content DB

Add the new version to the drop-down list of compatible Minetest versions that authors can select for their things.