>Sfan5 at 15:20, 18 July 2023

2023-07-18T15:20:06Z

New page

== 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
- [ ] (Minor/Major) Write blog post
- [ ] Ensure protocol version codes have been bumped
- Release
- [ ] Run bump_version and verify
- [ ] Push new tag
- [ ] 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 ===

(''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 (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 <code>language</code> setting enum values contain <code>en</code>: there is no "en" directory, but Minetest supports it.
Autogenerate config file examples such as <code>minetest.conf.example</code> (see bottom of <code>builtin/mainmenu/dlg_settings_advanced.lua</code>), etc.

Also update [[Translation|translation]] templates (engine, builtin and any default games). Note that before you regenerate translations, you most likely want to [[#Update_translations_from_Weblate|import existing changes]] first.

Look into the <code>util</code> sub-directory for tools like <code>updatepo.sh</code>.

=== 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 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 changelog ===

Changelog can be found [[Changelog|here]].

=== Ensure protocol version codes have been bumped ===

If not a patch release: ensure that PROTOCOL_VERSION has been increased since the last release. ([https://github.com/minetest/minetest/issues/11603 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 <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
** updates the version number and release date in misc/net.minetest.minetest.appdata.xml
** increments ''versionCode'' in build/android/build.gradle by 2
** 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 provide win32/64 packages as a '''fallback''': https://gitlab.com/minetest/minetest/pipelines
** Since 5.0, the 64-bit builds are compiled with GC64-enabled LuaJIT (to avoid [https://github.com/minetest/minetest/issues/2988 #2988])

→ → → '''''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.

* 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 ingame and look

=== Upload packages to somewhere ===

* All official builds are hosted at Github: https://github.com/minetest/minetest/releases
* Windows builds are uploaded by whoever builds them
* 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>minetest-5.x.x-osx.zip</code>. This is then uploaded.
* Android APKs are also uploaded here when they're done

=== Update branches and tags of minetest and minetest_game on GitHub ===

Tagging is handled by the script for the engine. For MTG you can just create an annotated tag pointing to the latest commit and push it.

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

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

celeron55, rubenwardy, and ShadowNinja have access.

Process:

* 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".
* 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.
** 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 ===

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

==== Signing APKs for the Play Store ====

* Run the Android build process as usual
* '''Sign the package:''' <code>"~/Android/Sdk/build-tools/29.0.3/apksigner" sign --ks keystore-minetest.jks .../app-armeabi-v7a-release.apk</code>
* EDIT: You can use Android Studio to generate bundles/apks if you upgrade the jks

==== Creating Native Debug Symbols ====

* 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 ==

=== 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 minetest.net 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]].'''
** 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 the [https://twitter.com/MinetestProject Twitter account]. 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 ===

* '''Arch Linux'''/Manjaro: can be flagged outdated on the [https://archlinux.org/packages/extra/x86_64/minetest/ package page]
* '''Alpine Linux''': can be flagged outdated on the [https://pkgs.alpinelinux.org/package/edge/community/x86_64/minetest package page]
* '''Debian'''/Ubuntu: has [https://tracker.debian.org/pkg/minetest own version tracking], no need to contact
* '''F-Droid''': has volunteer maintainers, if nobody notices consider opening an issue [https://gitlab.com/fdroid/fdroiddata/-/issues here]
* '''Snap''': open an issue (or contribute) [https://github.com/snapcrafters/minetest here]
* '''Flatpak''': open an issue (or contribute) [https://github.com/flathub/net.minetest.Minetest here]
* '''Gentoo''': has [https://packages.gentoo.org/packages/games-action/minetest own version tracking], no need to contact

You can find out how quick various distro are to adopt new versions [https://repology.org/project/minetest/history here on repology].

=== ContentDB ===

==== Add a new version ====

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

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

People who have access: rubenwardy + ???

==== Package devtest ====

The Minetest Game package on ContentDB makes a new release automatically when a new tag is made.

The [https://content.minetest.net/packages/Minetest/devtest/ Development Test] package however needs to be released '''manually'''. Make a new release, upload a ZIP file with Development Test like it looks like the Minetest source tree in the stable branch, and set the minimum and maximum Minetest versions to the Minetest version it is intended for.

[[Category:Core Engine]]
[[Category:Rules and Guidelines]]

Releasing Minetest - Revision history

>Sfan5 at 15:20, 18 July 2023