-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Support release branch naming with MAJOR SemVer number only #2679
Comments
I agree this should be supported. Pull requests are welcome. |
I'm currently unable to build GitVersion.MsBuild so I cannot test my suggested change (add "?" to ParseSemVer regex). That is an inhibitor to my raising a PR. |
As I'm interested in this feature as well, I created a PR with the suggested changes. |
…aming-with-major-only (GH-2679) Support release branch naming with MAJOR SemVer number only
Thank you. Sorry for late response, I have been away. |
🎉 This issue has been resolved in version 5.6.10 🎉 Your GitReleaseManager bot 📦🚀 |
it will conflict if you have something like release/test-build-23 it will set your major to 23 you will not able to set back using your tags. |
Support base version extraction from branch naming with just the number.
Detailed Description
Currently GitVersion does work with our branch naming convention which has release branch naming format:
release/<MAJOR>
The major portion of the base version number is not discovered from branches in a typical repository like:
release/0
release/1
release/2
...When we create a new release branch the version number (e.g. release/1 -> 1.0.0) is not picked up and a tag of v1 does not work either. However release/1.0 and a tag v1.0 do work.
Context
The change would allow GitVersion to be used without our branch numbering convention. This convention works well for us as we are daily adding bug fixes and/or features with a fairly short release cycle. Major version bumps are infrequent and result in customer code that is affectively orphaned and requires separate handling, so this branch name works very well for us.
Possible Implementation
Changing the text parsing in
SemanticVersion
to handle only such as3
-> 3.0.0 looks like it would fix the problem.I'm unable to build the code to test, but a fix looks like changing the regex in
SemanticVersion
to:private static readonly Regex ParseSemVer = new Regex( @"^(?<SemVer>(?<Major>\d+)(\.(?<Minor>\d+))?(\.(?<Patch>\d+))?)(\.(?<FourthPart>\d+))?(-(?<Tag>[^\+]*))?(\+(?<BuildMetaData>.*))?$", RegexOptions.Compiled);
And add the test case to
SemanticVersionTests.ValidateVersionParsing
:[TestCase("1", 1, 0, 0, null, null, null, null, null, null, null, null)]
The text was updated successfully, but these errors were encountered: