Public Access
54 lines
2.7 KiB
Markdown
54 lines
2.7 KiB
Markdown
# Dual-version release workflow
|
|
|
|
Maintain Minecraft 1.21.1 and 26.3 independently. The 1.21.1 line retains Dynamic
|
|
Dimensions AR Edition and Bad Packets. The 26.3 line uses its first-party backend.
|
|
Do not widen either artifact's Minecraft dependency range or import saves between
|
|
the tracks.
|
|
|
|
## Version identity
|
|
|
|
From 26.3.0.1 onward, prefix the Minecraft version and append the milestone/release
|
|
slice and iteration: Minecraft.release-slice.iteration. Example:
|
|
`26.3.0.1` -> `rivencraft-26.3.0.1.jar`, Gitea tag `V26.3.0.1`.
|
|
An explicitly selected prerelease uses a suffix such as `-beta.1`.
|
|
The existing 1.21.1 release keeps its published version until its next code update;
|
|
then use the corresponding `1.21.1.<slice>.<iteration>` convention.
|
|
|
|
The user authorized regular release status for 26.3.0.1. Release-channel status
|
|
does not close unfinished parity or multiplayer issues automatically.
|
|
|
|
## Build and publish
|
|
|
|
For 26.3, update `ports/mc263/gradle.properties`, then run
|
|
`./gradlew -p ports/mc263 build --console=plain` with Java 25 available.
|
|
Use the exact built/player-validated artifact; naming/metadata-only changes do
|
|
not change generation or save behavior.
|
|
|
|
Write release notes, audit the guide/wiki/project description, commit and push
|
|
the changes, then create and push the matching annotated tag. Preview the
|
|
`scripts/publish_mod_sites.py release` command with the JAR, changelog, version,
|
|
display name, Minecraft version, Java version and channel; add `--publish` to
|
|
upload to Gitea, Modrinth and CurseForge. Tokens stay in the system keyring.
|
|
Verify published metadata and downloaded artifact hashes. CurseForge approval
|
|
may remain pending after a successful upload.
|
|
|
|
The publisher accepts legacy Minecraft-prefixed archive filenames and beta tags
|
|
for already numbered historical uploads; new releases use the identity above.
|
|
|
|
## Validation gates and issue audit
|
|
|
|
Run appropriate builds and targeted server checks for changed behavior. The user
|
|
performs visual/gameplay validation. Keep temporary test fixtures out of shipped
|
|
JARs; use new worlds and remove them regardless of pass/fail. Stop test processes.
|
|
If generation stalls, hand the test to the user.
|
|
|
|
Before closing a port umbrella issue, compare its acceptance criteria and comments
|
|
to actual evidence. Current expanded-catalog two-client create/travel/reconnect/
|
|
restart/stale-ack regression remains in #100. #103 retains dual-line release
|
|
automation/regression completion and #104 retains the full parity gate.
|
|
Shared issues need both versions resolved before closure.
|
|
|
|
For each release, document tested optional versions and no-optional fallbacks,
|
|
match client/server JARs, preserve the independent 1.21.1 support line, update wiki
|
|
and platform descriptions, and keep known bugs linked in the release notes.
|