fix: release-please tag format#10
Merged
Merged
Conversation
release-please defaulted to include-component-in-tag: true, so it was expecting tags like `stackvox-v0.2.0`. Our actual tag is `v0.2.0` (single-package repo, no need for a package prefix). Release-please couldn't locate its expected lower-bound tag and fell back to "walk all history", which is why every release PR re-listed `feat(stackvox): first commit` under the new version's Features. Setting include-component-in-tag: false aligns the config with the tag format actually in use. On next push to main, release-please will close PR #7 and regenerate a clean release PR whose diff starts at the v0.2.0 tag. Co-Authored-By: Claude Opus 4.7 (1M context) <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
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.
Summary
Fixes the recurring "first commit appears as a 0.3.0 Feature" problem in release-please PRs (see PR #7 for the latest example).
Diagnosis
release-please's compare URL was pointing at `stackvox-v0.2.0...stackvox-v0.3.0` — i.e. it's been expecting tags of the form `stackvox-v{version}` the whole time. Our actual tag is just `v0.2.0` because we're a single-package repo. release-please couldn't resolve its expected lower-bound tag, so it fell back to walking history from the beginning, and every commit in the repo ended up in the proposed release.
The default for `include-component-in-tag` is `true` in release-please's manifest mode, even for single-package setups. We never overrode it.
Fix
Adds `"include-component-in-tag": false` to `release-please-config.json`. Now release-please will look for / generate `v{version}` tags, matching the one we already have.
What happens after merge
Test plan