saturnclient/VERSION_GUIDE.md

Version guide

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

Layout

Every supported Minecraft version (1.21.4 to 1.21.11) builds from one copy of the version-specific code with Stonecutter:

• 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.
• src/: the version-specific code (providers, refs, mixins and the three mixin configs), one copy for every version. Where Minecraft's API differs between versions, the code goes behind version comments (see below).
• versions/<mc>/: each version's gradle.properties (Minecraft, Fabric Loader and Fabric API versions), plus its build/ and run/ folders. Each version is the Gradle project :<mc>.

settings.gradle.kts lists the versions in stonecutterVersions. The root build.gradle.kts builds each version, and stonecutter.gradle.kts configures the root project (shared repositories, the common wiring and buildAll). Loom's version is loom_version in the root gradle.properties.

Mappings

Every version is built with Mojang's official names (loom.officialMojangMappings()), the names Minecraft itself ships from 26.1 on. Yarn isn't used any more: 1.21.11 has the last Yarn release.

Mojang renamed a few classes within 1.21.x. src/ uses the newest names, and stonecutter.gradle.kts lists replacements that swap in the older name when Stonecutter processes an older version (for example Identifier, which was ResourceLocation before 1.21.11, and AvatarRenderState, which was PlayerRenderState before 1.21.9). Add a replacement there when a rename touches many lines. A class that only moved package needs just a version comment on its import, and a renamed method a version comment where it's called.

Released jars run on intermediary names (method_1234), not Mojang's, and Loom renames everything that refers to Minecraft when it builds them. So a mixin can't implement one of common's Ref interfaces by relying on a vanilla method that happens to have the same name: the vanilla method is renamed in the jar, and the interface method is left without an implementation (AbstractMethodError). Shadow the vanilla method and implement the Ref method explicitly, as WindowMixin does. For the same reason, Ref methods mustn't share a name and parameters with a method of the class they're mixed into, or the mixin replaces the vanilla method in development.

Version-specific code with Stonecutter

The code in src/ is always plain Java for the active version (1.21.11, set in stonecutter.gradle.kts). Code for other versions sits in comments that Stonecutter swaps before building each version:

//? if >=1.21.9 {
public void submit(PoseStack matrices, SubmitNodeCollector output, int light, AvatarRenderState state, float limbAngle, float limbDistance) {
//?} else
//public void render(PoseStack matrices, MultiBufferSource output, int light, AvatarRenderState state, float limbAngle, float limbDistance) {

A condition without braces covers the next line only. For several lines, use braces and wrap the inactive block in /* … */:

//? if >=1.21.11 {
import net.minecraft.client.renderer.rendertype.RenderTypes;
import net.minecraft.client.renderer.rendertype.RenderSetup;
//?} else {
/*import net.minecraft.client.renderer.RenderStateShard.MultiTextureStateShard;
*///?}

Stonecutter rewrites inactive code into its own layout when switching versions (a single inactive line becomes //code), so write it that way to begin with, or run a switch and a reset before committing.

When a newer version leaves something out that an older one implements, keep the older version's code behind a condition and mark the newer branch with a TODO, rather than dropping it for every version. The panorama in SaturnScreenFabric.render is an example. Search for TODO to find what newer versions still lack (tracked in #30), and remove the condition once a version gap is fixed.

A whole class that only exists for some versions (such as MatrixStackMixin, which only makes sense before 1.21.6's GUI rewrite) can keep an empty class body on the other versions. Before splitting a class like that, look for a hook that works on every version: nametags used to hook label rendering, which 1.21.9 changed, and now replace the name while the render state is built (LivingEntityRendererMixin), with no version condition at all. An empty mixin changes nothing, and it keeps the mixin configs the same for every version, since JSON can't hold version comments.

Inactive code sits inside a /* … */ comment, so it can't contain /* … */ comments itself: use // comments in code that's only active for some versions. For the same reason, don't nest multi-line version blocks; use //?} else if <condition> { for more than two version ranges, as in PlayerEntityRendererMixin and SaturnRenderState.

• ./gradlew "Set active project to <mc>" (or the Stonecutter IntelliJ plugin) rewrites src/ so that version's code is the uncommented one, for editing it in the IDE.
• ./gradlew "Reset active project" switches back to 1.21.11. Run it before committing, so src/ is always committed with 1.21.11 active.
• Each version's processed copy is compiled from versions/<mc>/build/generated/stonecutter/, which is also where to look when a non-active version fails to compile.

The emotes repository uses the same setup, and its BentCubeRenderer and PlayerModelMixin are small examples of version comments.

Checking a change on every version

Since every version shares src/, a change applies to all of them at once. Code that uses the Minecraft API may still only compile on some, so build them all:

./gradlew compileJava

The Check workflow runs the same compile on every pull request, so a version a change doesn't compile on fails before merging. Mixins whose target changed fail at startup rather than at compile time, so launch the versions a change touches with ./gradlew :<mc>:runClient.

For bigger changes, ./gradlew buildAll builds every version's jar into build/allJars/.

Adding a Minecraft version

1. Create versions/<new>/gradle.properties with minecraft_version, loader_version and fabric_api_version (copy 1.21.11's and change the values; they're listed at https://fabricmc.net/develop). Loom's version is shared, in the root gradle.properties.
2. Add <new> to stonecutterVersions in settings.gradle.kts.
3. Build it with ./gradlew :<new>:compileJava and put what Minecraft changed behind version comments. 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 :<new>:runClient.
4. The release workflow builds everything through buildAll, and "Publish to Modrinth" takes the game version from each jar's name, so neither needs changing.