RELEASE.md

Create a new release

1. Update mod_version in gradle.properties.
2. Commit that change.
3. Push that commit.
4. Create a matching annotated git tag in the form vX.Y.Z so the tag message becomes the GitHub release notes.
5. For a short release note, run git tag -a v1.0.1 -m "Summarise the release here".
6. For longer release notes, put them in a file and run git tag -a v1.0.1 -F RELEASE_NOTES.md.
7. Push the tag with git push origin v1.0.1.

The release workflow reads the annotated tag message and uses it as the GitHub release body. If the tag has no annotation text, GitHub auto-generated release notes are used as a fallback. GitHub Actions checks out tag pushes in a way that can obscure annotated tag contents, so the workflow fetches the remote tag object before reading the notes.

When updating fabricmoddingconventions_version, publish and verify the matching FabricModdingConventions release on Maven Central before changing this template. The release must contain the runtime artifact, every Gradle plugin marker, and every matching plugin implementation module. Update the reusable workflow tags in .github/workflows/build.yml to the same version, then run the generated-template smoke matrix before releasing the template.

If MODRINTH_TOKEN is configured, the same workflow creates or updates the Modrinth project and publishes the release JAR. If both CURSEFORGE_TOKEN and CURSEFORGE_PROJECT_ID are configured, it publishes the same JAR to CurseForge. All destinations use the same tag notes. Missing third-party credentials skip only that destination; the GitHub Release still proceeds.