Repository navigation
chore: release the three packages as one unit, starting with a beta - #208
Merged
Merged
Conversation
The previous config declared each package separately, so merging the release PR
would have created three tags and three draft GitHub Releases. Publishing any
one of them fires publish.yml, which publishes all three packages - so the first
release would have done the whole job and the other two would have failed with
"cannot publish over the previously published versions". The changelog was also
split three ways, with no single place describing the release.
These packages are versioned in lockstep and published together, so they are
one releasable unit. The root is now the only release: one tag, one GitHub
release, one changelog. The three package.json versions are updated through
extra-files, which is what keeps them in step - the workspace: protocol plus
pnpm pack already handles the ranges between them.
Two things fall out of this. The grouped PR title interpolates ${version} again,
because release-please takes it from the release at path "." and there was not
one before. And the tag is v<version>, matching every tag this repo has used
since v4.
Also switches to prerelease versioning, so the next release is 5.1.0-beta
published to the `next` dist-tag. Dropping `prerelease`, `prerelease-type` and
`versioning` from the package graduates it to a stable 5.1.0 on `latest`.
Verified by dry run against this branch:
✔ updating from 1.0.0 to 5.1.0-beta
Would open 1 pull requests
updates: packages/plugin-rest-cache/package.json,
packages/provider-rest-cache-memory/package.json,
packages/provider-rest-cache-redis/package.json,
CHANGELOG.md, .release-please-manifest.json
Co-Authored-By: Claude <noreply@anthropic.com>
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
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.
Replaces #200 (closed). Three problems with how that PR would have released.
1. It would have created three releases, and two would have failed
Each package was declared separately, so merging produced three tags and three
draft GitHub Releases:
Publishing any one fires
publish.yml, which publishes all three packages.So the first would have done the entire release, and the second and third would
have failed with
cannot publish over the previously published versions: 5.1.0— two red runs immediately after a successful release.
2. The changelog was split three ways
Three
<details>sections, no single place describing the release.3. Fixed: one release, one changelog
These packages are versioned in lockstep and published together, so they are one
releasable unit. The root is now the only release — one tag, one GitHub release,
one
CHANGELOG.md. The threepackage.jsonversions are updated throughextra-files, which is what keeps them in step;workspace:+pnpm packalready handles the ranges between them.
Two things fall out of it:
${version}again.plugins/merge.jstakes itfrom the release at path
., and there wasn't one — which is why it read abare
chore: release.v<version>, matching every tag this repo has used since v4,and satisfying the
v*tag rule on thenpm-latest/npm-prereleaseenvironments.
4. Beta first
versioning: prerelease+prerelease-type: beta, so the next release is5.1.0-beta, published to thenextdist-tag via thenpm-prereleaseenvironment.
To graduate: drop
prerelease,prerelease-typeandversioningfrom thepackage and the following release is a stable
5.1.0onlatest. A second betaincrements rather than colliding —
bumpPrereleasebumps a trailing number.Verified by dry run against this branch
Note
prerelease: truealone does nothing — the version stayed5.1.0untilversioning: prereleasewas added. Both are needed.Known: duplicated changelog entries
Several entries appear twice with different shas:
That is real history —
594ba4ais the merge commit for #171 and56aeae4isthe commit on its branch. release-please walks all 82 commits since v5.0.0
rather than the 47 on first-parent, and both parse to the same conventional
commit. It is confined to the old merge-commit era; PRs are squashed now, so it
will not recur. Worth hand-editing out of the release notes on the draft before
publishing, since this one release sweeps up a year of history.
🤖 Generated with Claude Code