Files
saturnclient/VERSION_GUIDE.md
T
selimaj-devandclaude f73f7e733c
Check / compile (pull_request) Successful in 18m7s
Add a version port script and a compile check for pull requests
- scripts/port.sh ports a change made under versions/<from>/src to the
  other versions with `git apply --3way`: clean where files match,
  normal conflicts only where a version really differs. Supports
  uncommitted changes or --commit, --to, --dry-run, and detects changes
  already applied.
- .gitea/workflows/check.yml compiles every version on pull requests and
  pushes to master (--continue reports all failing versions).
- VERSION_GUIDE.md documents the layout, porting, and adding a version.

Closes #17, closes #18

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-26 02:41:22 +02:00

2.7 KiB

Version guide

How Saturn Client supports several Minecraft versions, and how to change or add one.

Layout

  • common/: all version-independent code (mods, UI, cosmetics, the server client). It has no Minecraft dependency and reaches the game only through the interfaces in org.saturnclient.common.
  • versions/<mc>/: one module per Minecraft version, implementing those interfaces (providers, refs, mixins). Each is a full copy, and they differ only where Minecraft's API differs.
    • gradle.properties: the Minecraft, Yarn, Fabric Loader and Fabric API versions.
    • src/: the version-specific code and the three mixin configs.

settings.gradle includes every folder under versions/ automatically, as the Gradle project :mc-<mc>.

Porting a change to the other versions

Make the change in one version, usually the newest, then run:

scripts/port.sh                        # port uncommitted changes to every other version
scripts/port.sh --dry-run              # see what would apply cleanly first
scripts/port.sh --to 1.21.9,1.21.10    # only some versions
scripts/port.sh --commit <rev>         # port what a commit changed instead

The script applies the diff under versions/<from>/src to each other version with git apply --3way:

  • applied: the files matched, and nothing else is needed.
  • CONFLICTS: that version's code really differs. The file gets normal conflict markers, with the version's own code in ours and the ported change in theirs. Adapt the change to that version's API and resolve.
  • already has this change: nothing to do, which is safe to see when re-running.

Only src/ is ported. build.gradle and gradle.properties are version-specific on purpose. Then build everything:

./gradlew compileJava

The Check workflow runs the same compile on every pull request, so a version that was missed or mis-ported fails before merging.

Adding a Minecraft version

  1. Copy the closest existing version: cp -r versions/1.21.11 versions/<new>. Delete its build/, .gradle/ and run/ folders if present.
  2. In versions/<new>/gradle.properties, set minecraft_version, yarn_mappings, loader_version and fabric_api_version. The right values are listed at https://fabricmc.net/develop.
  3. Build it with ./gradlew :mc-<new>:compileJava and fix what Minecraft changed. Check the mixin configs in src/main/resources/*.mixins.json as well: a mixin whose target changed fails at startup, not at compile time, so launch it with ./gradlew :mc-<new>:runClient.
  4. The release workflow builds every folder under versions/, and "Publish to Modrinth" takes the game version from each jar's name, so neither needs changing.