Releasing

Releases come from the “Release” workflow on GitHub. Nothing in the repository holds the version; the workflow takes it as input.

1. Add a ## X.Y.Z section to CHANGELOG.md, written for server owners: a patch for fixes, a minor version for features, a major one for breaking changes. Push it.

2. Run the workflow, from Actions → Release → Run workflow, or:

   gh workflow run release.yml -R MairwunNx/mojoins -f version=X.Y.Z -f modrinth=true -f hangar=true

3. Watch it: gh run watch.

What the workflow does

1. Takes the notes from the version’s CHANGELOG.md section, or from its changelog field.
2. Builds and tests with -PreleaseVersion=X.Y.Z.
3. Tags vX.Y.Z and creates a GitHub release with mojoins-X.Y.Z.jar and mojoins.jar, so releases/latest/download/mojoins.jar always fetches the newest.
4. With modrinth: uploads the jar to Modrinth (mojoins) and syncs MODRINTH.md as the project page.
5. With hangar: uploads the jar to Hangar (MairwunNx/MoJoins), Release channel. Hangar doesn’t sync its page; edit it on the site after a big change.
6. With moonlands (on by default): starts the shipping workflow of Moonlands, which puts the jar on the server.

The stores need the MODRINTH_TOKEN and HANGAR_TOKEN secrets, and Moonlands FAMILY_ACTIONS_TOKEN.

A version can’t be released twice: the workflow stops when its tag exists. Never delete or re-tag a published release; finish a half-failed one by hand.