Skip to content

chore: release the three packages as one unit, starting with a beta - #208

Merged
derrickmehaffy merged 1 commit into
mainfrom
chore/single-release-prerelease
Aug 14, 2026
Merged

derrickmehaffy merged 1 commit into
mainfrom
chore/single-release-prerelease

Conversation

@derrickmehaffy

Copy link
Copy Markdown
Contributor

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:

plugin-rest-cache-v5.1.0
provider-rest-cache-memory-v5.1.0
provider-rest-cache-redis-v5.1.0

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 three package.json versions are updated through
extra-files, which is what keeps them in step; workspace: + pnpm pack
already handles the ranges between them.

Two things fall out of it:

  • The PR title interpolates ${version} again. plugins/merge.js takes it
    from the release at path ., and there wasn't one — which is why it read a
    bare chore: release.
  • The tag is v<version>, matching every tag this repo has used since v4,
    and satisfying the v* tag rule on the npm-latest / npm-prerelease
    environments.

4. Beta first

versioning: prerelease + prerelease-type: beta, so the next release is
5.1.0-beta, published to the next dist-tag via the npm-prerelease
environment.

To graduate: drop prerelease, prerelease-type and versioning from the
package and the following release is a stable 5.1.0 on latest. A second beta
increments rather than colliding — bumpPrerelease bumps a trailing number.

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

Note prerelease: true alone does nothing — the version stayed 5.1.0 until
versioning: prerelease was added. Both are needed.

Known: duplicated changelog entries

Several entries appear twice with different shas:

* add a cache statistics endpoint for the admin dashboard (594ba4a)
* add a cache statistics endpoint for the admin dashboard (56aeae4)

That is real history — 594ba4a is the merge commit for #171 and 56aeae4 is
the 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

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>
@derrickmehaffy
derrickmehaffy merged commit 3498f3a into main Aug 14, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant