Build 1.21.6 with Stonecutter from the shared src/

1.21.6's copy only differed from 1.21.7's in RenderScopeImpl: item rendering uses ItemRenderState, which 1.21.7 renamed to KeyedItemRenderState. That's behind a version comment; 1.21.6 keeps its older loader_version (0.18.5) in its gradle.properties. Moving a version over leaves the old mc-<v> project's compiled classes in the shared build/ folder, so a removed class (1.21.6's dead NameTagMixin) still got packaged until a clean. VERSION_GUIDE now says to run :<v>:clean once after moving a version. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-27 06:10:31 +02:00
parent 6f122b5237
commit a949c18ec1
60 changed files with 12 additions and 3706 deletions
@@ -7,8 +7,8 @@ How Saturn Client supports several Minecraft versions, and how to change or add
 Saturn is moving from one full copy of the version-specific code per Minecraft version to a single copy built with [Stonecutter](https://stonecutter.kikugie.dev/) (issue #8). During the move there are two kinds of version:

 - `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) for the versions built by Stonecutter, currently **1.21.7 to 1.21.11**. It's one copy: where Minecraft's API differs between them, the code goes behind version comments (see below). Each of these versions is the Gradle project `:<mc>`, and `versions/<mc>/` holds only its `gradle.properties` (Minecraft, Yarn, Fabric Loader and Fabric API versions), `build/` and `run/`.
- `versions/<mc>/src/`: the versions not moved yet (1.21.4 to 1.21.6), each a full copy, as the Gradle project `:mc-<mc>` with its own `build.gradle`.
+- `src/`: the version-specific code (providers, refs, mixins and the three mixin configs) for the versions built by Stonecutter, currently **1.21.6 to 1.21.11**. It's one copy: where Minecraft's API differs between them, the code goes behind version comments (see below). Each of these versions is the Gradle project `:<mc>`, and `versions/<mc>/` holds only its `gradle.properties` (Minecraft, Yarn, Fabric Loader and Fabric API versions), `build/` and `run/`.
+- `versions/<mc>/src/`: the versions not moved yet (1.21.4 and 1.21.5), each a full copy, as the Gradle project `:mc-<mc>` with its own `build.gradle`.

 `settings.gradle.kts` lists the Stonecutter versions in `stonecutterVersions` and includes every other folder under `versions/` as `:mc-<mc>`. The root `build.gradle.kts` builds each Stonecutter version, and `stonecutter.gradle.kts` configures the root project (shared repositories, the `common` wiring and `buildAll`). Loom's version for the Stonecutter versions is `loom_version` in the root `gradle.properties`.

@@ -55,7 +55,7 @@ Make the change in one version, usually the newest, then run:
 ```sh
 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.5,1.21.6     # only some versions
+scripts/port.sh --to 1.21.4,1.21.5     # only some versions
 scripts/port.sh --commit <rev>         # port what a commit changed instead
 ```

@@ -78,6 +78,6 @@ The **Check** workflow runs the same compile on every pull request, so a version
 Add new versions to Stonecutter rather than copying a folder:

 1. Create `versions/<new>/gradle.properties` with `minecraft_version`, `yarn_mappings`, `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`.
+2. Add `<new>` to `stonecutterVersions` in `settings.gradle.kts`. When moving an existing `mc-<v>` version over instead, delete its `versions/<v>/src` and run `./gradlew :<v>:clean` once: the new project shares the old one's `build/` folder, and classes compiled from the removed sources would otherwise end up in the jar.
 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.