Difference between revisions of "Releasing Minetest"

From Minetest Developer Wiki
Jump to navigation Jump to search
m (→‎Update translations on Weblate: notify translators)
(More general updates)
Line 3: Line 3:
 
=== Announce a 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).
+
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.
 
The feature freeze and release date is set by core developers.
Line 29: Line 30:
 
=== Update version in source ===
 
=== Update version in source ===
  
* '''Define''' a new version number by running util/bump_version.sh. Verify that this script correctly.
+
* '''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 ANDROID_VERSION_CODE in build/android/build.gradle
+
** 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.
Line 39: Line 40:
 
=== Build Windows version ===
 
=== Build Windows version ===
  
* These can either be built with Visual Studio or MinGW. Performance may vary sometimes, but is negligible.
+
* These are built for 32-bit and 64-bit using either Visual Studio or MinGW. (sfan5 typically provides MinGW builds)
* Since 0.4.8, a MinGW build is published, built by sfan5.
 
 
* If at all possible, debug builds (for both MSVC and MinGW) should be produced along with the regular release 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
 
* As of April 2018, this GitLab pipeline can alternatively provide win32/64 packages: https://gitlab.com/minetest/minetest/pipelines
Line 48: Line 48:
 
==== Tweak Windows package a bit ====
 
==== Tweak Windows package a bit ====
  
* Include Minetest Game or other subgames that were decided on before the release.
+
* Include Minetest Game and other subgames that were decided on before the release.
* Include msvcr100.dll and wrap_oal.dll in the package (bin/). ''This hasn't been done since several releases, still applicable?''
 
 
* 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.
 
* 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.  
 
* Generally, Those making official builds probably already know what they are doing.  
Line 55: Line 54:
 
=== Upload Windows package to somewhere ===
 
=== Upload Windows package to somewhere ===
  
* Windows packages are hosted at GitHub: https://github.com/minetest/minetest/releases.
+
* Windows packages are hosted at GitHub: https://github.com/minetest/minetest/releases
  
 
=== Update branches and tags of minetest and minetest_game on GitHub ===
 
=== Update branches and tags of minetest and minetest_game on GitHub ===
Line 62: Line 61:
 
* 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 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 engine's stable-0.4 branch [LEGACY] ====
+
==== The problem on the engine's stable-5 branch ====
Usually, merging releases onto the stable-0.VER_MINOR branch just consists of adding the commits to the branch, as the stable-0.VER_MINOR branch contains direct anchestors of master commits, and git can do a fast forward. During release/freeze of 0.4.12, 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-0.4 are all discarded in favour of the tagged commit at master, by doing a merge commit like:
+
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, 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 checkout version-tag
     git merge -s ours origin/stable-0.4
+
     git merge -s ours origin/stable-5
     git push origin HEAD:stable-0.4
+
     git push origin HEAD:stable-5
  
 
=== Update Launchpad stable build to get Ubuntu builds for the new version ===
 
=== Update Launchpad stable build to get Ubuntu builds for the new version ===
Line 87: Line 86:
 
* '''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.
 
* '''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 ====
 
==== 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:
+
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
 
* '''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
 
* '''Zipalign the apk:''' zipalign -v 4 bin/Minetest-release-unsigned.apk Minetest-release.apk
Line 106: Line 105:
  
 
* Don't forget to edit the [http://www.minetest.net minetest.net] page.
 
* Don't forget to edit the [http://www.minetest.net minetest.net] page.
* Usually 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.
 
* Announce the release on the [https://twitter.com/MinetestProject Twitter account]. rubenwardy has access.
  
Line 116: Line 115:
 
* '''neoascetic''' (mail address on [https://github.com/neoascetic his GitHub profile page]) maintains Minetest in the OS X Homebrew repository.
 
* '''neoascetic''' (mail address on [https://github.com/neoascetic his GitHub profile page]) maintains Minetest in the OS X Homebrew repository.
 
* '''Akien''' (@ chat.freenode.net) maintains the minetest package in Mageia.
 
* '''Akien''' (@ chat.freenode.net) maintains the minetest package in Mageia.
* '''sofar''' (@ chat.freenode.net) maintains the packages for Clear Linux (Intel's linux distribution).
+
* '''sofar''' (@ chat.freenode.net) maintains the packages for Clear Linux (Intel's Linux distribution).
 
<!-- TODO: Find more. -->
 
<!-- TODO: Find more. -->
  
 
[[Category:Core Engine]]
 
[[Category:Core Engine]]
 
[[Category:Rules and Guidelines]]
 
[[Category:Rules and Guidelines]]

Revision as of 09:42, 4 October 2019

Before releasing

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

Autogenerate config file examples such as minetest.conf.example, etc.

Also update translation templates (both engine and any default games).

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

Update translations on Weblate

Make sure that the translations on hosted.weblate.org (or on whatever online translation platform our translations are currently hosted) are up-to-date. Please also notify translators so they can start working.

Update changelog

Changelog can be found here.

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

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

Update branches and tags of minetest and minetest_game on GitHub

  • See previous tags. Use the same tag for all of them; eg. "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 engine's 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, 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, est31, and ShadowNinja have access.

Process:

  • Go to the 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).
  • Click "Request builds" and wait for builds to complete.

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


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

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