chore: manage releases with release-please - #8
Merged
Conversation
Replaces the tag-triggered lerna release. Pushing a v* tag by hand meant deciding the version by hand; release-please derives it from the conventional commits that landed and keeps a release PR open with the changelog it will publish, so the version follows from the commits rather than being a judgement call at release time. Versions stay in lockstep via the linked-versions plugin, which is what lerna.json's fixed mode was expressing. They had already drifted, with cli and example at 2.4.3 and the other four at 2.4.2, so this normalises everything to 2.4.3 and aligns the interdependency ranges to match. node-workspace keeps those ranges updated on future releases. The example package is private and is not listed for release. Publishing moves from `lerna publish from-git` to `from-package`, because release-please creates the tags itself; from-git looks for tags lerna made and would find none. The publish job is gated on releases_created, so an ordinary push to master only refreshes the release PR. chore and docs commits are hidden from the changelog but still land; feat, fix, perf, refactor, build and ci are surfaced. The next release is intended to be 3.0.0. The flattened history already carries BREAKING CHANGE footers for the package rename and the Node 24 and ESM-only move, so release-please will arrive at that on its own rather than needing to be told. Nothing here forces a release; the version lands whenever the accumulated breaking changes are ready to go out.
emmanuel
force-pushed
the
chore/release-please
branch
from
September 6, 2026 18:30
cfee7b5 to
8cceb70
Compare
emmanuel
added a commit
that referenced
this pull request
Sep 6, 2026
Replaces the tag-triggered lerna release. Pushing a v* tag by hand meant deciding the version by hand; release-please derives it from the conventional commits that landed and keeps a release PR open with the changelog it will publish, so the version follows from the commits rather than being a judgement call at release time. Versions stay in lockstep via the linked-versions plugin, which is what lerna.json's fixed mode was expressing. They had already drifted, with cli and example at 2.4.3 and the other four at 2.4.2, so this normalises everything to 2.4.3 and aligns the interdependency ranges to match. node-workspace keeps those ranges updated on future releases. The example package is private and is not listed for release. Publishing moves from `lerna publish from-git` to `from-package`, because release-please creates the tags itself; from-git looks for tags lerna made and would find none. The publish job is gated on releases_created, so an ordinary push to master only refreshes the release PR. chore and docs commits are hidden from the changelog but still land; feat, fix, perf, refactor, build and ci are surfaced. The next release is intended to be 3.0.0. The flattened history already carries BREAKING CHANGE footers for the package rename and the Node 24 and ESM-only move, so release-please will arrive at that on its own rather than needing to be told. Nothing here forces a release; the version lands whenever the accumulated breaking changes are ready to go out.
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.
Second of three stacked PRs. Based on #7; retargets to master once that merges.
Replaces the tag-triggered lerna release. Pushing a
v*tag by hand meantdeciding the version by hand. release-please derives it from the conventional
commits that landed and keeps a release PR open with the changelog it will
publish, so the version follows from the commits rather than being a judgement
call at release time.
Lockstep versioning
Via the
linked-versionsplugin, which is whatlerna.json's fixed mode wasexpressing. The versions had already drifted — cli and example at 2.4.3, the
other four at 2.4.2 — so this normalises everything to 2.4.3 and aligns the
interdependency ranges.
node-workspacekeeps those ranges updated on futurereleases.
exampleis private and is not listed for release.Publishing
Moves from
lerna publish from-gittofrom-package: release-please createsthe tags itself, so
from-gitwould look for tags lerna made and find none. Thepublish job is gated on
releases_created, so an ordinary push to master onlyrefreshes the release PR.
choreanddocsare hidden from the changelog but still land;feat,fix,perf,refactor,buildandciare surfaced.The next release is 3.0.0
The flattened history already carries
BREAKING CHANGEfooters for the packagerename and the Node 24 / ESM-only move, so release-please arrives at 3.0.0 on
its own rather than needing to be told. Nothing here forces a release — the
version lands whenever the accumulated breaking changes are ready to go out,
and more are expected before then.
Checked
Repo Actions settings already allow workflows to create pull requests
(
default_workflow_permissions: write,can_approve_pull_request_reviews: true), so release-please can open its PR. I could not read the org-levelpolicy, which can override this.