chore: pin the next release to 1.0.0 via release-as - #72
Merged
Conversation
The graduation commit (#70) manually set the manifest to 1.0.0 in the same commit that also carried a `!` breaking marker - release-please treated that marker as new unreleased work on top of the manifest we'd already bumped, computing 1.0.0 + major = 2.0.0 (PR #71, closed unmerged, never tagged/released). Pinning release-as: 1.0.0 tells release-please to target exactly 1.0.0 for its next PR instead of computing a bump on top of the current manifest value. Per release-please's own docs, this should be removed (or bumped) once that 1.0.0 release PR merges, or later runs will keep reusing it.
There was a problem hiding this comment.
Pull request overview
Pins the next Release Please run to target version 1.0.0 explicitly, preventing an accidental semver “major bump on top of an already-bumped manifest” scenario and aligning the next release PR with the intended baseline.
Changes:
- Add
"release-as": "1.0.0"to Release Please config for the root package (".").
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
2 tasks
bougyman
added a commit
that referenced
this pull request
Aug 12, 2026
## Summary - Removes the `"release-as": "1.0.0"` pin added in #72, now that `v1.0.0` has actually shipped (#73). - Per release-please's own docs, this pin must be removed (or bumped) once the release it targets merges - otherwise future runs keep reusing `1.0.0` instead of computing normal semver bumps from conventional commits. ## Test plan - [x] JSON validated - [x] Diff confirmed to be exactly the state right after v1.0.0 shipped, minus the pin 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.
Summary
1.0.0in the same commit that also carried a!breaking-change marker. Release-please treated that marker as new unreleased work on top of the manifest we'd already bumped, computing1.0.0 + major = 2.0.0(opened as chore(main): release 2.0.0 #71, closed unmerged - never tagged or released, confirmed viagh release list/git ls-remote --tags)."release-as": "1.0.0"to.release-please-config.jsonso release-please targets exactly1.0.0for its next PR instead of computing a bump on top of the current manifest value.Follow-up
Per release-please's own docs,
release-asshould be removed (or bumped) once the resultingchore(main): release 1.0.0PR merges - otherwise future runs keep reusing this pin instead of computing normal semver bumps. Tracking this so it doesn't get forgotten.Test plan
actionlintre-run on.github/workflows/main.yaml- unaffected, still cleanv2.0.0tag/release exists anywhere (gh release list,git ls-remote --tags origin)🤖 Generated with Claude Code