selimaj-devandclaude
eebfe8fa4d
Check / compile (pull_request) Successful in 7m47s
- settings.gradle, stonecutter.gradle and the root build.gradle become .kts. Loom's version for the Stonecutter versions moves to the root gradle.properties (loom_version), read by pluginManagement, since the Kotlin plugins block can't read properties. The old mc-<v> projects keep their Groovy scripts until they're folded in. - buildAll ran all eight remapJar tasks at once. Each loads a Minecraft classpath and remaps a ~50 MB jar, which doesn't fit in the 3 GB daemon heap: a cold build stalled in garbage collection for 40+ minutes, and earlier runs failed. A shared build service now lets two remaps run together; a cold buildAll takes about 2 minutes. - port.sh and VERSION_GUIDE follow the .kts file names. The 1.21.11 jar is the same as with the Groovy scripts. Co-Authored-By: Claude Opus 5.5 <[email protected]>
65 lines
4.8 KiB
Markdown
65 lines
4.8 KiB
Markdown
# Version guide
|
|
|
|
How Saturn Client supports several Minecraft versions, and how to change or add one.
|
|
|
|
## Layout
|
|
|
|
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.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.10), 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`.
|
|
|
|
## 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:
|
|
|
|
```java
|
|
//? if >=1.21.9 {
|
|
public void render(MatrixStack matrices, OrderedRenderCommandQueue queue, int light, PlayerEntityRenderState state, float limbAngle, float limbDistance) {
|
|
//?} else
|
|
/*public void render(MatrixStack matrices, VertexConsumerProvider consumers, int light, PlayerEntityRenderState state, float limbAngle, float limbDistance) {*/
|
|
```
|
|
|
|
- `./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.
|
|
|
|
## Porting a change to the other versions
|
|
|
|
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.9,1.21.10 # only some versions
|
|
scripts/port.sh --commit <rev> # port what a commit changed instead
|
|
```
|
|
|
|
The script applies the diff under one version's source to each other version with `git apply --3way`. The Stonecutter `src/` counts as one version (1.21.11), so changes port between it and the old copies in both directions:
|
|
|
|
- **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 source is ported. `build.gradle` and `gradle.properties` are version-specific on purpose. Then build everything:
|
|
|
|
```sh
|
|
./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
|
|
|
|
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`.
|
|
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.
|