chore: remove the release-as 4.1.0 override from the release-please config - #203
Merged
Merged
Conversation
…onfig The override was added in #195 to force the hardening release to 4.1.0 instead of 4.0.5, but release-as is a standing instruction, not a one-shot: left in place after #163 released 4.1.0, it made release-please propose v4.1.0 again for every subsequent release PR (#197), which collided with the existing v4.1.0 tag when merged. With the override removed, release-please computes the next version from conventional commits again. A future forced version should use a Release-As footer on an empty commit instead, which applies to a single release and leaves nothing behind.
There was a problem hiding this comment.
🟢 Approval recommended
The change is a straightforward config correction that removes a persistent version pin without introducing any functional code or JSON validity issues.
Pull request overview
Removes the persistent release-as override from the release-please configuration so release versions are computed from conventional commits again, preventing repeated proposals of an already-released tag.
Changes:
- Deleted
"release-as": "4.1.0"fromrelease-please-config.jsonto stop pinning future releases to 4.1.0.
File summaries
| File | Description |
|---|---|
| release-please-config.json | Removes the standing release-as override so release-please returns to normal version calculation. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
Root-cause fix for the accidental #197 merge (now removed from main's history).
#195 added
"release-as": "4.1.0"to force the hardening release to 4.1.0 instead of 4.0.5. The field is a standing instruction, not a one-shot: after #163 released 4.1.0 it stayed in the config, so release-please kept proposing v4.1.0 (#197), and merging that PR tried to re-tag the already-released version.This PR removes the override so release-please computes versions from conventional commits again. Note that everything on main since v4.1.0 is
refactor:/test:/docs:, none of which bump the version, so no release PR will appear until afeat:orfix:lands. To release the current changes as 4.1.1 now, merge an empty commit carrying aRelease-As: 4.1.1footer; unlike the config field, the footer applies to a single release and leaves nothing behind.