Maintenance Rules

Deprecation

Any compatibility code added to keep unmaintained or deprecated mods shall be itself removed after at most 5 years.

Minor mod updates

In order to keep the game up-to-date and a provide WhyNot gamers the benefits of fixes and features from upstream mod development, the WhyNot maintenance team will do the following tasks at least once a month:

1. Run the update_mods.sh script
2. For each mod that has changed:
   1. Review the commits for anything that looks like it might break compatibility with existing gamers' worlds, or substantially affect gameplay.
   2. Look at the diff for more details
   3. Merge if the changes look minor/trivial/low impact. Do not merge otherwise (skip), and see Major mod updates instructions below.
3. Once the script has run and the results are satisfactory, you may push the new commits directly into the main branch.
4. On github draft a new release.
   1. In "Choose a tag", type the date in YYYY-MM-DD format. Use the same for the release title. In the description, simply use the "Generate release notes" which will include a link to the list of commits, and diff changes since the previous release.

Major mod updates

Major mod updates usually fall in one of the following categories:

• New mod added, or mod removed (for whatever reason)
• A mod that has changes susceptible of breaking compatibility with existing gamers' worlds (whether in itself, or interacting with other mods).
• Changes substantial enough to warrant more careful code review by multiple people and play testing.
• Changes substantial enough to warrant re-evaluation of the WhyNot rules.

In those cases, a major update should be performed for a single mod as follows:

1. Create an issue to evaluate and review the changes more closely.
2. Create a git branch in which the changes will be committed.
3. Use the update_mod.sh script, skipping all other updates but the one mod in question. This should result in two commits (the mod in question, and the "Update mod_sources.txt")
4. If the change breaks backward compatibility, an exception may be added in the lib-config-whynot. If needed, an issue could also be created in the upstream repository.
5. Push the new branch, and create a pull request detailing the nature of the changes, why they are considered major, and why they should be included. Link the issue created in (1) by using the appropriate Github keywords.
6. Once the pull request is completed, draft a new release .
   1. In "Choose a tag", type the date in YYYY-MM-DD format. Use the same for the release title. In the description, simply use the "Generate release notes" which will include the pull request details, a link to the list of commits, and diff changes since the previous release.

Translation

Most of the content in WhyNot? will be translated upstream. There are some exceptions, like the WhyNot? awards, or the contentDB strings. In these cases, we rely on Weblate for community translations at https://hosted.weblate.org/projects/whynot-game-for-minetest/

However, since Weblate does not support Minetest's translation file format, the maintainers must follow the instructions outlined in https://codeberg.org/Wuzzy/Repixture/src/branch/master/DEV_TRANSLATION_WORKFLOW.md, using the tools in https://codeberg.org/Wuzzy/Minetest_Translation_Tools and https://github.com/minetest/modtools.

Additionally, the Weblate commits are pushed to the translations branch. As such these changes will not be automatically merged into the game. There is an additional merge needed from the translations branch to the main one for translation changes to appear in the game.