Latitude Release Discipline

Preflight invariants (must be true)

1. Working tree clean (or only intended version bump changes)
2. Correct branch checked out for the target
3. gradle.properties contains the correct mod_version for that target
4. ./gradlew clean build succeeds
5. The built jar filename matches the intended release string
6. Jar contents do not include extracted sources or tooling folders
7. Tag points at the commit that produced the jar

One-step-at-a-time release protocol (mandatory)

Step A — Confirm branch + cleanliness

Run:

• git status
• git branch --show-current

Rules:

• If git status shows local changes that would block checkout, stash with a message.
• If the branch is wrong, checkout the correct branch before doing anything else.

Step B — Confirm version string (no guessing)

On the target branch:

• Inspect gradle.properties and confirm:
  • mod_version=...

Required patterns:

• 1.21.11 build: 1.2.5+1.21.11 (example)
• 1.21.1 build: 1.2.5+1.21.1 (example)

If the jar name later shows a different version, the branch’s mod_version is wrong. Fix gradle.properties, commit, rebuild.

Step C — Clean build with isolated Gradle home

Run from repo root:

$env:GRADLE_USER_HOME = "$PWD\.gradle-user-home"
.\gradlew clean build --no-daemon

Then list jars:

Get-ChildItem .\build\libs\*.jar | Select-Object Name, Length, LastWriteTime

Rule:

• If the expected jar is not present, do not proceed.

Step D — Verify jar contents (must do once per release file)

Inspect the jar you will upload:

jar tf .\build\libs\<YOUR_JAR_NAME>.jar | findstr /I "_mcsrc_extract .windsurf SKILL.md com/mojang blaze3d"

Pass criteria:

• No matches.

If there are matches:

• STOP. Rebuild from a clean branch and fix .gitignore or build config.

Step E — Tag discipline (tags must match jar)

Preferred tags:

• v<mod_version> (example: v1.2.5+1.21.11)

Rules:

• Tag must be created/moved only after the jar is confirmed correct.
• If you must move a tag, use -f and force-push only that tag.

Commands:

git tag -f v<mod_version>
git push origin -f v<mod_version>

Step F — Upload discipline (Modrinth)

Rules:

• A single Modrinth release may contain multiple files.
• Each file must be assigned the correct game versions.
• Never upload a “fixed jar” without also ensuring the tag/branch state matches.

Minimum changelog bullets must include:

• the user-facing fix summary
• any important regression fix (UI, crashes)
• optional: debug flags are dev-only

Branch hygiene rules (absolute)

• main is the only allowed release base for 1.21.11.

• compat/1.21.1 is the only allowed release base for 1.21.1.

• Feature branches may contain experiments and must not own release tags.

• Extracted sources and tooling folders must never be part of a release commit:

  • _mcsrc_extract/
  • .windsurf/
  • other generated extraction folders

If something is confusing, diagnose like this

1. List jars in build/libs
2. Confirm current branch
3. Confirm mod_version in gradle.properties
4. Rebuild
5. Re-list jars
6. Only then tag/upload

No other order is allowed.