chore: release main - #282
Merged
Merged
Conversation
StefanSteiner
force-pushed
the
release-please--branches--main
branch
from
September 6, 2026 21:58
5bf64dc to
a513ce3
Compare
This was referenced Sep 6, 2026
StefanSteiner
added a commit
that referenced
this pull request
Sep 6, 2026
…e setup (#285) Four claims in docs/GITHUB_OPERATIONS.md described a release pipeline that does not exist. Each was checked against the config, the workflows, and the last two release PRs before being rewritten. 1. Lockstep versioning was attributed to a `linked-versions` plugin. release-please-config.json has no `plugins` key at all. Lockstep falls out of the config declaring exactly one package whose version is fanned out through `extra-files` and `x-release-please-start-version` markers. Documented the real mechanism and added an explicit warning not to "fix" the discrepancy by adding the plugin, which would push the repo toward a multi-package layout it does not want. 2. Step 2 promised "a new dated section in each crate's CHANGELOG.md". `changelog-path` is set on the `.` package only, and neither #282 nor #255 touches a per-crate changelog. Since AGENTS.md reminder 8 still asks contributors to append to those files, nothing ever rolls them over: 110 bullets across the nine crates currently sit under `## [Unreleased]` describing work shipped as far back as v0.1.1. Added a documented manual rollover step to the release checklist rather than moving the files under release-please, which would require the nine-package layout. The same step also claimed package.json versions and optionalDependencies are bumped in the release PR. No package.json in the tree carries either field; npm-build-publish.yml materializes both at publish time. 3. "All 8 workspace members share a single version number" undercounts the lockstep set, which is 9 path crates — hyperdb-compile-check is outside the workspace but is still version-managed and published. The other two counts in the file ("8 Rust crates" published, "9 path crates in all") were already right and are unchanged. 4. `bump-minor-pre-major: true` is gated on `version.isPreMajor`, i.e. `major < 1`, so it has been inert since 1.0.0-rc.1. Annotated rather than removed: it is behaviour-neutral either way, and editing the file that drives releases while a release PR is open buys nothing. Also documents the rc tripwire, verified with `release-please@17.11.2` dry runs (the version release-please-action@v5 pins): during an rc line a `Release-As:` footer is required on every release, and without one a `fix:` computes 1.0.1-rc.2, a `feat:` 1.1.0-rc.2, and a breaking change 2.0.0-rc.2 — all well-formed enough to pass both publish workflows' tag validation, and all sorting above 1.0.0. CONTRIBUTING.md contradicted GITHUB_OPERATIONS.md on whether the publish workflows must be triggered by hand. They fire from `release: published`; `gh workflow run` is only for re-runs.
StefanSteiner
force-pushed
the
release-please--branches--main
branch
2 times, most recently
from
September 6, 2026 23:34
909b48f to
5a4b007
Compare
StefanSteiner
added a commit
that referenced
this pull request
Sep 6, 2026
Add the three prerelease keys to the "." package in release-please-config.json so the rc counter increments on its own: "prerelease": true, "prerelease-type": "rc", "versioning": "prerelease" Before this, the config had no prerelease keys, so release-please applied the default strategy: it bumped major.minor.patch and carried the -rc.N suffix along unchanged. From 1.0.0-rc.2 a `fix:` computed 1.0.1-rc.2 -- well-formed, publishable, and sorting *above* 1.0.0, so publishing it would have made a later 1.0.0 final a downgrade. Producing the next rc required a Release-As: footer on every single release, in the squash commit body, and forgetting it was the default outcome. See #283. With the keys in place, every releasing prefix (fix:, feat:, feat!:) computes 1.0.0-rc.3 instead. Release-As: still wins when present, so it remains available to pin a specific version. Also remove `bump-minor-pre-major` (both occurrences). release-please only consults it when version.isPreMajor -- defined as major < 1 -- so it has been inert since 1.0.0-rc.1. Dry runs confirmed removing it changes no computed version under either config. This discharges a deferred item from the 1.88 uplift plan. Verified with `release-please@17.6.0 release-pr --dry-run` (17.6.0 is what release-please-action@v5 actually bundles) against real config files on pushed branches, after first reproducing the live 1.0.1-rc.2 that PR #282 computed. Cross-checked on 17.11.2; both agree on every case. The caveat this introduces: the keys must be removed, or `prerelease` flipped to false, when 1.0.0 final ships -- otherwise the next `fix:` computes 1.0.1-rc (verified). That failure is visible in the release PR title and reversible, unlike the silent one it replaces. Documented in the release checklist, next to the bump table, and in a dedicated "Graduating to 1.0.0" section. Refs #283
StefanSteiner
force-pushed
the
release-please--branches--main
branch
from
September 6, 2026 23:35
b982ef4 to
c6f7ee6
Compare
StefanSteiner
force-pushed
the
release-please--branches--main
branch
2 times, most recently
from
September 7, 2026 01:55
8377011 to
249629e
Compare
StefanSteiner
force-pushed
the
release-please--branches--main
branch
from
September 7, 2026 02:47
a4e6620 to
c140c38
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 I have created a release beep boop
1.0.0-rc.3
1.0.0-rc.3 (2026-09-07)
Bug Fixes
Performance Improvements
This PR was generated with Release Please. See documentation.