chore: start the 1.0 release candidate cycle

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 |

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" }]
     }