fix: next-version should not require the tag-prefix to parse - #5248
akashchamp wants to merge 1 commit into
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe configured ChangesNext-version parsing
Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to Plain 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Tick the box to add this pull request to the merge queue (same as
|
`next-version` is a version, not a tag, so `ConfiguredNextVersionVersionStrategy`
no longer strips the configured `tag-prefix` before parsing it. Previously,
when `tag-prefix` did not accept an empty/optional prefix (e.g.
`tag-prefix: 'package-a/'`), any `next-version` value that didn't also start
with that same prefix failed to parse ("Failed to parse 1.2.3 into a Semantic
Version"), forcing users to write `next-version: package-a/1.2.3` instead of
the plain version.
BREAKING CHANGE: `next-version` values that were prefixed with `tag-prefix` as
a workaround for the parsing failure above will now fail to parse and must be
changed to the plain version instead.
Resolves GitTools#5228
580c7fe to
f44177f
Compare
|
This branch has not been deployed
2 participants
Description
next-versionis a version, not a tag, so it should never need theconfigured
tag-prefixstripped from it before parsing. Before this change,ConfiguredNextVersionVersionStrategyparsednext-versionwithSemanticVersion.Parse(nextVersion, Context.Configuration.TagPrefixPattern, ...)— the same call used for actual Git tags. When
tag-prefixwas set tosomething that does not also accept an empty/optional match (e.g.
tag-prefix: 'package-a/'), that regex requires the prefix to be present atthe start of the string, so any
next-versionthat didn't also start withthe prefix failed to parse.
This PR makes the
next-versionvalue parse as-is by passingnullinsteadof
TagPrefixPatterntoSemanticVersion.Parse, matching how the rest of thetest suite already parses standalone (non-tag) version strings.
Related Issue
Resolves #5228
Motivation and Context
Reported in #5228: in a monorepo with a non-optional per-package
tag-prefix(e.g.
package-a/), settingnext-version: 1.4.5throwsFailed to parse 1.4.5 into a Semantic Version. The only workaround was toduplicate the prefix into
next-versionitself (next-version: package-a/1.4.5),even though
next-versionis never matched against a Git ref and has noreason to carry a tag prefix. Maintainer confirmation: "Yea, this makes
sense. Pull requests welcome!" (asbjornu, on the issue).
This is a breaking change for anyone currently using the
next-version: <tag-prefix><version>workaround — that value will now failto parse and must be changed to the plain version. Documented in
BREAKING_CHANGES.mdunder "Unreleased".How Has This Been Tested?
MainScenarios.NextVersionInConfigDoesNotRequireTagPrefix, aRepositoryFixtureintegration test that configuresTagPrefixPattern = "package-a/"andNextVersion = "1.0.0"on thedevelopbranch with a single untagged commit, and assertsAssertFullSemver("1.0.0-alpha.1", configuration).GitVersion.WarningException: Failed to parse 1.0.0 into a Semantic VersionfromSemanticVersion.Parseon the code as it stood before thischange, and passes after the fix.
GitVersion.Core.Testssuite (dotnet test src/GitVersion.Core.Tests/GitVersion.Core.Tests.csproj) after the change —all tests pass, including the existing
ConfiguredNextVersionVersionStrategyTestsparameterized cases and the
CanSpecifyTagPrefixes/CanSpecifyTagPrefixesAsRegex/AreTagsNotAdheringToTagPrefixIgnoredtag-prefix scenarios in
MainScenarios, confirming actual Git-tag parsing(which still needs
tag-prefixstripped) is unaffected.Screenshots (if appropriate):
N/A (CLI/library behavior change, no UI).
Checklist:
docs/claim about this behavior existed to correct; the breaking-change note lives inBREAKING_CHANGES.md, see above)Summary by CodeRabbit
next-versionis now parsed as a version value without applying the tag prefix. Update values such aspackage-a/1.2.3to1.2.3to ensure version calculations use the intended version.next-versionformat.