Difference between revisions of "Releasing Luanti"

From Minetest Developer Wiki
Jump to navigation Jump to search
m (→‎Update translations on Weblate: Remove "important")
(various updates)
 
(68 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
== Before releasing ==
+
== Checklist ==
 +
 
 +
<pre>
 +
- Feature freeze
 +
  - [ ] Announced
 +
  - [ ] Release candidate advertised
 +
  - [ ] Weblate sources regenerated and strings frozen
 +
- Pre-release (day of release)
 +
  - [ ] Autogenerate files
 +
  - [ ] Correct special strings on Weblate (`LANG_CODE`)
 +
  - [ ] Update translations from Weblate
 +
  - [ ] Update changelog
 +
  - [ ] Update credits in repo
 +
  - [ ] Update credits on website
 +
  - [ ] (Minor/Major) Write blog post
 +
  - [ ] Ensure protocol version codes have been bumped
 +
- Release
 +
  - [ ] Run bump_version and verify
 +
  - [ ] Push new tag
 +
  - [ ] Tag minetest_android_deps repo
 +
  - [ ] Build and upload Windows version
 +
  - [ ] Build and upload Android version
 +
  - [ ] (Minor/Major) Publish blog post
 +
  - [ ] Create forum topic
 +
  - [ ] Notify rubenwardy to announce on Twitter, etc.
 +
  - [ ] Notify downstream maintainers
 +
</pre>
 +
 
 +
== Feature Freeze ==
  
 
=== Announce a feature freeze ===
 
=== Announce a feature freeze ===
  
 +
(''Skip for patch releases'')
 
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.
 
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).
+
To find high priority issues faster, consider linking a release candidate binary to get more test results. This release candidate is usually also posted on the forums (News section).
  
 
The feature freeze and release date is set by core developers.
 
The feature freeze and release date is set by core developers.
Line 10: Line 39:
 
=== Autogenerate files ===
 
=== Autogenerate files ===
  
−
Autogenerate config file examples such as <code>minetest.conf.example</code>, etc.
+
Also update the [[Translation|translation]] templates:
 +
 
 +
* Engine: Regenerate Gettext files with <code>util/updatepo.sh</code>. Note that before that, you most likely want to [[#Update_translations_from_Weblate|import existing changes]] first.
 +
* Builtin: Change directory to <code>builtin</code>, then run <code>util/mod_translation_updater.py</code> from there
  
−
Also update [[Translation|translation]] templates (both engine and any default games).
+
Also ensure that the <code>language</code> setting enum values contains <code>en</code>: there is no "en" directory, but Luanti supports it.
  
−
Look into the <code>util</code> sub-directory for tools like <code>updatepo.sh</code>.
+
Read [[Translation]] for details.
  
−
=== Update translations on Weblate ===
+
=== Update source strings on Weblate ===
  
−
Make sure that the translations on hosted.weblate.org (or on whatever online [[Translation|translation]] platform our translations are currently hosted) are up-to-date. Please also notify translators so they can start working.
+
Make sure that the source strings on hosted.weblate.org are up-to-date.
  
−
Do '''not''' just blindly run the scripts without checking. Check if the translations on Weblate were ''actually'' updated. A simple way to check this 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.
+
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 Luanti, this means the update failed.
 +
 
 +
== Before releasing ==
 +
 
 +
=== Verify special translation strings ===
 +
 
 +
The translation files contain a special string: [https://hosted.weblate.org/translate/minetest/minetest/en/?q=LANG_CODE&checksum=&offset=1#translations LANG_CODE] (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:
 +
<source>
 +
git log --reverse --pretty=format:"%h" $BASE..weblate/master -- po | xargs -L1 git cherry-pick
 +
</source>
 +
 
 +
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 main menu credits ===
 +
 
 +
This consists of:
 +
* Making use of <code>util/gather_git_credits.py</code>
 +
** edit the <code>REVS_ACTIVE</code> variable to contain the version number of two major versions in the past (e.g. 5.6.0 if you are releasing 5.8.0)
 +
** run the script
 +
* Editing <code>builtin/mainmenu/credits.json</code> and putting the results there
 +
* Don't forget to update the list of core developers if that changed
 +
 
 +
=== Update website credits ===
 +
 
 +
Once the credits are decided on in the previous step, update the website to be in sync with the mainmenu.
 +
Simply copy the same <code>credits.json</code> to here: https://github.com/minetest/minetest.github.io/tree/master/_data
  
 
=== Update changelog ===
 
=== Update changelog ===
  
 
Changelog can be found [[Changelog|here]].
 
Changelog can be found [[Changelog|here]].
 +
 +
=== Ensure protocol version codes have been bumped ===
 +
 +
If not a patch release: ensure that <code>PROTOCOL_VERSION</code> has been increased since the last release. ([https://github.com/minetest/minetest/issues/11603 deciding discussion])
 +
 +
If formspec features have been added: ensure <code>LATEST_FORMSPEC_VERSION</code> has been increased since the last release.
  
 
== The process ==
 
== The process ==
Line 32: Line 103:
 
=== Update version in source ===
 
=== Update version in source ===
  
−
* '''Define''' a new version number by running <code>util/bump_version.sh</code>. Verify that this script correctly.
+
The process with patch releases is slightly different but the script will take care of it correctly in any case.
 +
 
 +
* '''Define''' a new version number by running <code>util/bump_version.sh</code>. Verify that this script correctly:
 
** changes TRUE to FALSE for the line ''set(DEVELOPMENT_BUILD TRUE)'' in CMakeLists.txt
 
** 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
 
** updates the version number and release date in misc/net.minetest.minetest.appdata.xml
−
** increments ''versionCode'' in build/android/build.gradle
 
 
** and commits.
 
** 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.
+
* '''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''', get newest minetest_game, run and check if the thing seems to be working.
  
 
=== Build Windows version ===
 
=== Build Windows version ===
  
−
* These are built for 32-bit and 64-bit using either Visual Studio or MinGW. (sfan5 typically provides MinGW builds)
+
As of [https://github.com/minetest/minetest/pull/14098 December 2023], we use the '''mingw''' artifacts of the "windows" CI workflow.
−
* If at all possible, debug builds (for both MSVC and MinGW) should be produced along with the regular release builds.
+
* Extract the outer ZIP file so that users only have one ZIP file to extract (should be named <code>luanti-5.x.x-win64.zip</code>)
−
* As of April 2018, this GitLab pipeline can alternatively provide win32/64 packages: https://gitlab.com/minetest/minetest/pipelines
 
  
−
'''''Make sure that the Windows builds work before continuing to do anything!!'''''
+
Note that the correct build only shows up after the release commit has been pushed to Github.
  
−
==== Tweak Windows package a bit ====
+
→ → → '''''Make sure that the Windows builds work before continuing to do anything''''' ← ← ←
  
−
* Include Minetest Game and other subgames that were decided on before the release.
+
==== Mini checklist of things to test ====
−
* 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 ===
+
''Note'': Don't cheat on this by testing in Wine, it has happened that things crash/break in wine while they are fine on real Windows.
  
−
* Windows packages are hosted at GitHub: https://github.com/minetest/minetest/releases
+
* check that the build identifies itself as 5.x.x not 5.x.x-dev or 5.x.x-abc4de7
 +
* click some menu buttons
 +
* create world with MTG, enter it, exit back to menu
 +
* open multiplayer tab, attempt to join a server
 +
* install a package from CDB, uninstall it again
 +
* enable dynamic shadows, join in-game and look
  
−
=== Update branches and tags of minetest and minetest_game on GitHub ===
+
=== Upload packages to somewhere ===
  
−
* Tag the master branch same as in previous releases: eg. name it "5.0.0".
+
* All official builds are hosted at Github: https://github.com/minetest/minetest/releases
−
* 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 Windows build is created by CI
 +
** (see above)
 +
* The macOS build is created by [https://github.com/minetest/minetest/actions/workflows/macos.yml Github Actions]
 +
** you will only be able to grab the build '''after''' the release has been pushed
 +
** download the artifact, unpack it once, you should have a <code>luanti-5.x.x-osx.zip</code>. This is then uploaded.
 +
* Android APKs are also uploaded here when they're done
 +
** these are signed before uploading, see a few sections below
 +
 
 +
=== Update branches and tags of minetest on GitHub ===
 +
 
 +
Tagging is handled by the script for the engine.
 +
 
 +
The new release should be merged to the stable-5 branch on both minetest.
 +
'''Its important to merge, and not just rebase''', so that git describe works.
  
 
==== The problem on the stable-5 branch ====
 
==== 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.
+
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 ancestor 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:
+
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 favor of the tagged commit at master, by doing a merge commit like:
  
 
     git checkout version-tag
 
     git checkout version-tag
 
     git merge -s ours origin/stable-5
 
     git merge -s ours origin/stable-5
 
     git push origin HEAD:stable-5
 
     git push origin HEAD:stable-5
 +
 +
=== Tag Android deps ===
 +
 +
Create a new tag [https://github.com/minetest/minetest_android_deps/tags on this repo] with the version number of the release.
 +
This is to make it easier to figure out which state an APK was built from.
  
 
=== Update Launchpad stable build to get Ubuntu builds for the new version ===
 
=== Update Launchpad stable build to get Ubuntu builds for the new version ===
  
−
celeron55, est31, and ShadowNinja have access.
+
celeron55, rubenwardy, and ShadowNinja have access.
  
 
Process:
 
Process:
−
* Go to the [https://code.launchpad.net/~minetestdevs/+recipe/minetest-stable recipe], open the upstream and upstream_game repos (linked in the recipe at the bottom) and click "Import now" to update launchpad's copy of the repos. The packaging repo usually does not need updates unless Minetest has a new dependency.
+
 
−
* Once the repos have finished importing, edit the recipe with the new version and commit hashes and save. Use commit hashes from the stable-<version> branches (just policy, no technical requirement).
+
* Go to [https://code.launchpad.net/~minetestdevs/minetest-c55/+git/upstream minetest-c55/upstream] and [https://code.launchpad.net/~minetestdevs/minetest-c55/+git/upstream_game minetest-c55/upstream_game] and click "start import".
−
* Click "Request builds" and wait for builds to complete.
+
* First, find out the commit hashes of the minetest and minetest_game git repos corresponding to the release.
 +
* Now visit the [https://code.launchpad.net/~minetestdevs/+recipe/minetest-stable 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 <code>5.1.1-ppa0</code>. 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.
 +
* 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.
 
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.
 
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 ===
+
=== Build and publish Android APK ===
  
−
'''Notify''' the Android maintainers to update their APKs for their corresponding platforms:
+
'''nerzhul''' or '''rubenwardy''' have access to Google Play. Both also hold the signature keys for the app.
−
* '''nerzhul''' (@ 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.
 
−
==== How-to for binary release app stores ====
 
−
You can do the following step to upload minetest to app stores like Google Play, where you only can submit an app in binary form:
 
−
* '''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
 
  
 +
==== Signing APKs for the Play Store ====
  
 +
* Wait for CI to finish
 +
* Download the .aab from GitHub CI
 +
* Sign: <code>Android/Sdk/build-tools/34.0.0/apksigner sign --ks ~/Documents/keystore-minetest.jks --min-sdk-version 21 ~/Downloads/app-release.aab</code>
 +
* Upload to Google Play
 +
 +
==== Creating Native Debug Symbols ====
 +
 +
'''FIXME''': nobody does this anymore. what now?
 +
 +
* Copy native/build/intermediates/ndkBuild/release/obj/local/ to new folder
 +
* Remove all but .so files from new folder
 +
* Check the .so contain debug info using the file command
 +
* <code>zip -r symbols.zip .</code>
  
 
== After releasing ==
 
== After releasing ==
Line 100: Line 206:
 
=== Reenable -dev version suffix ===
 
=== Reenable -dev version suffix ===
  
 +
(''Skip for patch releases'')
 
Check that the util/bump_version.sh script did the following steps:
 
Check that the util/bump_version.sh script did the following steps:
  
Line 108: Line 215:
 
=== Write a release notice ===
 
=== Write a release notice ===
  
−
* Don't forget to edit the [http://www.minetest.net minetest.net] page.
+
* Don't forget to edit the luanti.org page ([https://github.com/minetest/minetest.github.io Repo]).
 +
** currently you will need to update machine readable metadata in _data/release.yml and downloads.html itself.
 
* Post a new topic in the [https://forum.minetest.net/viewforum.php?f=18 News section] of the forum. '''See [[Changelog]].'''
 
* Post a new topic in the [https://forum.minetest.net/viewforum.php?f=18 News section] of the forum. '''See [[Changelog]].'''
−
* Announce the release on the [https://twitter.com/MinetestProject Twitter account]. rubenwardy has access.
+
** It is customary to sticky the newest release topic and lock older ones.
 +
* Add a new post to the [https://github.com/minetest/blog/ blog]
 +
* Announce the release on [https://twitter.com/MinetestProject Twitter] and [https://mastodon.online/@Luanti@fosstodon.org Mastodon]. rubenwardy has access.
 +
 
 +
=== Update wiki version template ===
 +
 
 +
There is a special wiki template containing the version number at [https://wiki.minetest.net/Template:Version], used to make updating various wiki pages by hand less tedious. Update it so it includes the latest version.
  
 
=== Notify known package maintainers ===
 
=== Notify known package maintainers ===
  
−
* '''emptty''' (@ chat.freenode.net; Martin Quinson) maintains Debian packages.
+
* '''Arch Linux'''/Manjaro: can be flagged outdated on the [https://archlinux.org/packages/extra/x86_64/minetest/ package page]
−
* 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).
+
* '''Debian'''/Ubuntu: has [https://tracker.debian.org/pkg/minetest own version tracking], no need to contact
−
* '''nerzhul''' (@ chat.freenode.net) maintains the FreeBSD port and uploads new releases to the Google/Android Play Store.
+
* '''Fedora''' and others: should automatically show up [https://release-monitoring.org/project/1978/ here], but can be flagged manually
−
* '''neoascetic''' (mail address on [https://github.com/neoascetic his GitHub profile page]) maintains Minetest in the OS X Homebrew repository.
+
* '''F-Droid''': has volunteer maintainers, if nobody notices consider opening an issue [https://gitlab.com/fdroid/fdroiddata/-/issues here]
−
* '''Akien''' (@ chat.freenode.net) maintains the minetest package in Mageia.
+
* '''Snap''': open an issue (or contribute) [https://github.com/snapcrafters/minetest here]
−
* '''sofar''' (@ chat.freenode.net) maintains the packages for Clear Linux (Intel's Linux distribution).
+
* '''Flatpak''': open an issue (or contribute) [https://github.com/flathub/net.minetest.Minetest here]
−
<!-- TODO: Find more. -->
+
* '''Gentoo''': has [https://packages.gentoo.org/packages/games-engines/minetest own version tracking], no need to contact
 +
 
 +
You can find out how quick various distro are to adopt new versions by visiting [https://repology.org/project/minetest/history Repology].
 +
 
 +
=== ContentDB ===
 +
 
 +
==== Add a new version ====
 +
 
 +
Add the new version to the drop-down list of compatible Luanti versions that authors can select for their things.
 +
 
 +
Note that CDB tells Luanti versions apart by their protocol version so this is obviously not applicable to patch releases.
 +
 
 +
People who have access: rubenwardy + ???
 +
 
 +
==== Package devtest ====
 +
 
 +
Minetest Game is no longer connected to our release cycle, so we can ignore it.
 +
 
 +
The [https://content.minetest.net/packages/Minetest/devtest/ Development Test] package needs to be released '''manually'''.
 +
Make a new release, upload a ZIP file with Development Test as it looks like the Luanti source tree in the stable branch, and set the minimum and maximum Luanti versions to the exact Luanti version it is intended for.
  
 
[[Category:Core Engine]]
 
[[Category:Core Engine]]
 
[[Category:Rules and Guidelines]]
 
[[Category:Rules and Guidelines]]

Latest revision as of 13:58, 11 November 2024

Checklist

- Feature freeze
  - [ ] Announced
  - [ ] Release candidate advertised
  - [ ] Weblate sources regenerated and strings frozen
- Pre-release (day of release)
  - [ ] Autogenerate files
  - [ ] Correct special strings on Weblate (`LANG_CODE`)
  - [ ] Update translations from Weblate
  - [ ] Update changelog
  - [ ] Update credits in repo
  - [ ] Update credits on website
  - [ ] (Minor/Major) Write blog post
  - [ ] Ensure protocol version codes have been bumped
- Release
  - [ ] Run bump_version and verify
  - [ ] Push new tag
  - [ ] Tag minetest_android_deps repo
  - [ ] Build and upload Windows version
  - [ ] Build and upload Android version
  - [ ] (Minor/Major) Publish blog post
  - [ ] Create forum topic
  - [ ] Notify rubenwardy to announce on Twitter, etc.
  - [ ] Notify downstream maintainers

Feature Freeze

Announce a feature freeze

(Skip for patch releases) 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. 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

Also update the translation templates:

  • Engine: Regenerate Gettext files with util/updatepo.sh. Note that before that, you most likely want to import existing changes first.
  • Builtin: Change directory to builtin, then run util/mod_translation_updater.py from there

Also ensure that the language setting enum values contains en: there is no "en" directory, but Luanti supports it.

Read Translation for details.

Update source strings on Weblate

Make sure that the source strings on hosted.weblate.org are up-to-date.

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 Luanti, this means the update failed.

Before releasing

Verify special translation strings

The translation files contain a special string: LANG_CODE (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 main menu credits

This consists of:

  • Making use of util/gather_git_credits.py
    • edit the REVS_ACTIVE variable to contain the version number of two major versions in the past (e.g. 5.6.0 if you are releasing 5.8.0)
    • run the script
  • Editing builtin/mainmenu/credits.json and putting the results there
  • Don't forget to update the list of core developers if that changed

Update website credits

Once the credits are decided on in the previous step, update the website to be in sync with the mainmenu. Simply copy the same credits.json to here: https://github.com/minetest/minetest.github.io/tree/master/_data

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. (deciding discussion)

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

The process with patch releases is slightly different but the script will take care of it correctly in any case.

  • 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
    • 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

As of December 2023, we use the mingw artifacts of the "windows" CI workflow.

  • Extract the outer ZIP file so that users only have one ZIP file to extract (should be named luanti-5.x.x-win64.zip)

Note that the correct build only shows up after the release commit has been pushed to Github.

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

Mini checklist of things to test

Note: Don't cheat on this by testing in Wine, it has happened that things crash/break in wine while they are fine on real Windows.

  • check that the build identifies itself as 5.x.x not 5.x.x-dev or 5.x.x-abc4de7
  • click some menu buttons
  • create world with MTG, enter it, exit back to menu
  • open multiplayer tab, attempt to join a server
  • install a package from CDB, uninstall it again
  • enable dynamic shadows, join in-game and look

Upload packages to somewhere

  • All official builds are hosted at Github: https://github.com/minetest/minetest/releases
  • The Windows build is created by CI
    • (see above)
  • The macOS build is created by Github Actions
    • you will only be able to grab the build after the release has been pushed
    • download the artifact, unpack it once, you should have a luanti-5.x.x-osx.zip. This is then uploaded.
  • Android APKs are also uploaded here when they're done
    • these are signed before uploading, see a few sections below

Update branches and tags of minetest on GitHub

Tagging is handled by the script for the engine.

The new release should be merged to the stable-5 branch on both minetest. 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 ancestor 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 favor 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

Tag Android deps

Create a new tag on this repo with the version number of the release. This is to make it easier to figure out which state an APK was built from.

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

celeron55, rubenwardy, 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.
  • 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

nerzhul or rubenwardy have access to Google Play. Both also hold the signature keys for the app.

Signing APKs for the Play Store

  • Wait for CI to finish
  • Download the .aab from GitHub CI
  • Sign: Android/Sdk/build-tools/34.0.0/apksigner sign --ks ~/Documents/keystore-minetest.jks --min-sdk-version 21 ~/Downloads/app-release.aab
  • Upload to Google Play

Creating Native Debug Symbols

FIXME: nobody does this anymore. what now?

  • Copy native/build/intermediates/ndkBuild/release/obj/local/ to new folder
  • Remove all but .so files from new folder
  • Check the .so contain debug info using the file command
  • zip -r symbols.zip .

After releasing

Reenable -dev version suffix

(Skip for patch releases) 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 luanti.org page (Repo).
    • currently you will need to update machine readable metadata in _data/release.yml and downloads.html itself.
  • Post a new topic in the News section of the forum. See Changelog.
    • It is customary to sticky the newest release topic and lock older ones.
  • Add a new post to the blog
  • Announce the release on Twitter and Mastodon. rubenwardy has access.

Update wiki version template

There is a special wiki template containing the version number at [1], used to make updating various wiki pages by hand less tedious. Update it so it includes the latest version.

Notify known package maintainers

  • Arch Linux/Manjaro: can be flagged outdated on the package page
  • Debian/Ubuntu: has own version tracking, no need to contact
  • Fedora and others: should automatically show up here, but can be flagged manually
  • F-Droid: has volunteer maintainers, if nobody notices consider opening an issue here
  • Snap: open an issue (or contribute) here
  • Flatpak: open an issue (or contribute) here
  • Gentoo: has own version tracking, no need to contact

You can find out how quick various distro are to adopt new versions by visiting Repology.

ContentDB

Add a new version

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

Note that CDB tells Luanti versions apart by their protocol version so this is obviously not applicable to patch releases.

People who have access: rubenwardy + ???

Package devtest

Minetest Game is no longer connected to our release cycle, so we can ignore it.

The Development Test package needs to be released manually. Make a new release, upload a ZIP file with Development Test as it looks like the Luanti source tree in the stable branch, and set the minimum and maximum Luanti versions to the exact Luanti version it is intended for.

Retrieved from "http://dev.minetest.net/index.php?title=Releasing_Luanti&oldid=6673"