Skip to content

Release maintenance

Release behaviour is defined by the current workflows and repository settings, not by an old checklist copied from an upstream release. Treat historical release prose as input to review until every command is confirmed.

Before a release

  • select and record the exact source commit and version identity;
  • require stable default-branch checks for intended platforms and feature sets;
  • review save, data, Lua API, mod, translation, packaging, and security impact;
  • confirm third-party licenses, attributions, and release-note provenance;
  • generate documentation and API snapshots from the same source commit;
  • verify signing and publishing credentials through protected environments, never through repository files or logs.

Artifacts and verification

For every artifact record platform, architecture/ABI, build type, feature options, source commit, workflow run, checksums, and signing state. Test install or extraction and one startup/load path. Android APK/AAB, Windows packages, and Linux artifacts are distinct evidence.

Large Doxygen output, compile databases, indexes, profiles, and symbol databases remain CI/release artifacts rather than tracked source. Retention and backups must include a restore test, not only successful upload.

After publication

Publish release notes, API changelog, known compatibility issues, documentation snapshot, and rollback or hotfix route. Confirm download links and the player entry point. A failed or partially published release is recorded explicitly; do not silently replace an artifact under the same identity.