SuperTux release checklist

[Mathnerd314]

I looked, but there seems to be no documentation about how to make a new SuperTux release. This means that releases may be of inconsistent quality.

Presumably such a checklist should live on the wiki. My imagination as to what it would look like:

1. Build binaries
2. Upload binaries to Github
3. Upload binaries to Supertux.org
4. Send out announcement on Twitter

[Semphriss]

@Mathnerd314 Would it be better to have this in Discussions instead? I generally find discussions better suited for designing something new as they give a better commenting structure, lets the most supported comments appear first and allow an old proposal to be brought back at the top of the list when there is new activity, unlike issues.

[Mathnerd314]

How many people does it take to write a simple checklist? :laughing:

[Mathnerd314]

But sure, if you think it's better as a discussion then make it a discussion, I don't mind.

[Semphriss]

Well, as many as there are maintainers :smile:

For instance:

• Steam: How should those be handled? Builds may have a review delay, and announcements may or may not be produced each release.
• For point 2: GitHub Actions already handle uploading releases to GitHub, no action is needed. Should we also setup a CI for other platforms? For the website? How would we do that?
• How do we handle announcements on GitHub? (Do we do announcements at all?)
• Speaking of which, what do we put in the announcements? (Especially given the constraints of some services, like Twitter's length limit)
• Should we contact maintainers for various Linux distros, *BSD packagers, Brew, WinGet and more to handle their updating of SuperTux? Should we use the CI to help them perform the updates automatically? Should we implement service-specific actions in our CI? How should we do it for each maintainer?
• Google Play and other platforms with specific needs: How should their packaging be handled? Do they need specific build options? Always, conditionally? If conditionally, when to set a given option?
• Related to above: Should we strictly stick to CI builds to be distributed, or should we allow someone to compile SuperTux on their own computer for distribution? This can be necessary sometimes, but it will reduce the assurance that the builds are reproducible with a known, easy-to-find source code + build instructions.

All of this has to be decided while keeping in mind plenty of people will replace each other during SuperTux's history, so we shouldn't design this just for ourselves. If I (or anybody) happens to be absent for a release, for any reason, the team should be able to proceed without the missing people.

[Semphriss]

#2119 is the discussion for this issue.