From 2b40d8326df8caed4de3ec94da9d013aaaf2c446 Mon Sep 17 00:00:00 2001 From: Kenny Van de Maele Date: Tue, 3 Nov 2026 16:09:56 +0100 Subject: [PATCH] chore: start the 1.0 release candidate cycle Use the current game as the first 1.0 release candidate. Mark candidates as GitHub prereleases so the update check keeps regular players on full releases. Refs #77 Release-As: 1.0.0-rc.1 --- docs/port/platform.md | 2 ++ release-please-config.json | 3 +++ 2 files changed, 5 insertions(+) diff --git a/docs/port/platform.md b/docs/port/platform.md index 4f7684f2..311b73cf 100644 --- a/docs/port/platform.md +++ b/docs/port/platform.md @@ -153,6 +153,8 @@ Changes go to `main` through pull requests. Each pull request, and each push to Releases come from [release-please](https://github.com/googleapis/release-please) ([`release.yml`](../../.github/workflows/release.yml), [`release-please-config.json`](../../release-please-config.json)). Commit messages follow [Conventional Commits](https://www.conventionalcommits.org): `feat` for a new feature, `fix` for a bug fix, `docs` for documentation, and `build`, `ci`, `chore`, `perf`, `refactor` or `test` for the rest, with a `!` after the type for a breaking change. From these, release-please keeps a release pull request open with the next version and the changelog so far. Before 1.0, a feature raises the minor version, a fix the patch version, and a breaking change the minor version. A patch of an earlier version comes from a release branch cut from its tag, with the fix copied onto it, such as `release/0.5` from `v0.5.0` for 0.5.1: the workflow runs on the release branches too, and release-please keeps a release pull request for the branch. On `main`, `build.zig.zon` holds the version being worked towards, so a build from `main` reports itself as a build of it, such as `0.7.0+47.gabc1234`, and accepts the mods made for it. Raise it to the next minor version once a release comes from `main`. `.release-please-manifest.json` holds the last release, from `main` or a release branch, which release-please works out the next version from: after a patch release, raise it on `main` too. +For the 1.0 release candidates, the package uses `"versioning": "prerelease"`, `"prerelease-type": "rc"` and `"prerelease": true`. A commit body with `Release-As: 1.0.0-rc.1` starts the cycle; keep that line in the squash commit when merging the preparation pull request. Later fixes advance the candidate number, such as `1.0.0-rc.2`. To publish the final release, remove these three settings and put `Release-As: 1.0.0` in the commit body. Each candidate is marked as a GitHub prerelease. The game's update check reads GitHub's latest full release, so players download candidates by hand. A candidate does not notify players about later candidates, but it does notify them when the final 1.0.0 release is out. + Merging the release pull request updates [`CHANGELOG.md`](../../CHANGELOG.md) and the version in `build.zig.zon`, tags the version, and publishes a GitHub release with that version's changelog as its notes. The workflow then builds `openreliant` and `sltool` for each system and attaches the archives, each named for the version and the system, such as `openreliant-v0.6.1-linux-x86_64.tar.gz`, so another project's workflow can download the one it needs by version, for example to pack a mod with `sltool`: | Archive | Built on | Target | diff --git a/release-please-config.json b/release-please-config.json index b95cca56..c94098be 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -19,6 +19,9 @@ "packages": { ".": { "package-name": "openreliant", + "versioning": "prerelease", + "prerelease-type": "rc", + "prerelease": true, "initial-version": "0.0.1", "extra-files": [{ "type": "generic", "path": "build.zig.zon" }] }