-
Notifications
You must be signed in to change notification settings - Fork 653
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
[Bug] Mainline mode not properly using next-version #2335
Comments
This is strange. Can you try to delete your GitVersion/src/GitVersionCore.Tests/VersionCalculation/NextVersionCalculatorTests.cs Lines 91 to 118 in 5330bbb
|
If I delete gitversion.yml it works like I expect, except it's defaulting to version 0.1.0 so my versions in the branch are 0.1.0-branch0001. I just tried it in a brand new repository, here are the exact steps I took: mode: Mainline
next-version: 1.0.0 And at that point, I run gitversion and the generated version is And I merged bajurny into master (whose only changes are the gitversion.yml) and then gitversion returns |
What version number do you get if you remove |
Getting a chance to play around with this again. If I remove mode: Mainline then GitVersion properly returns a 1.0.0 prerelease number, if I add mode: Mainline back in it creates a 1.0.1 prerelease. So it looks like that test case tests the case with no mode specified, but not with Mainline, and it also sounds like this is a bug rather than a documentation issue. |
I wrote two failing tests, it looks like mainline mode isn't properly using next-version, perhaps treating the next-version as the already deployed version, rather than truly the next version. The first test is when inside a branch, setting next-version to 1.0.0, and gitversion returns 1.0.1-foo.1 instead of 1.0.0-foo.1. I tried to poke around at the source code to try and find where this might be happening but I'm not very fluent in C# so I wasn't able to immediately figure out where it might be happening.
From what I can tell it's properly finding the next-version, but then I suspect the mainline code isn't using it properly, but I haven't found where those parts are glued together yet to try and get a better idea of the logic. |
Please take a look at the mainline mode tests we have and whether they are covering your scenario at all. If not, we would welcome a PR with more tests and a fix that hopefully doesn't break a bunch of the existing tests. GitVersion/src/GitVersionCore.Tests/IntegrationTests/MainlineDevelopmentMode.cs Lines 16 to 546 in e705d37
|
None of the Mainline tests include Next-Version, which seems to be the source of the problem. I've written failing tests and opened a PR, and I'll keep looking over the code to see if I can find out what's happening. |
🎉 This issue has been resolved in version 5.5.0 🎉 Your GitReleaseManager bot 📦🚀 |
A small thing, but I never updated the title of this to reflect that it was actually a bug rather than a documentation issue, I've updated the title to more accurately describe the actual bug found. If you want to move this under "Bug" rather than "Documentation" in the release notes, that would be more accurate, but it's a small thing and I don't mind either way |
I think we keep it like this |
Those particularly interested can always click from the release notes to the particular issue and get the right title, so I agree with @arturcic that this is fine as is. |
I'm trying to use GitVersion in a brand new project of mine, using GitHub Flow and mainline mode, and I'm having trouble configuring it to behave the way I'd like/am expecting to.
I've been able to use GitVersion in an existing project of mine, where I'm able to tag the most recent release. For example if I've released 1.2.3, I can tag that in Git. On changes in a new branch, GitVersion will generate 1.2.4-branch0001 versions, which is what I'm expecting and what I want.
But I can't seem to figure out how to replicate this same behavior before I have any kind of release. What I would imagine I do is set the next-version in my config to 1.0.0, then versions will be generated like 1.0.0-branch0001, 1.0.0-branch0002, etc, until I merge into master, gitversion generates 1.0.0, and Git is tagged with that version. At that point I can remove next-version and rely on GitVersion seeing the Git tags to determine the next version. However when I set next-version to 1.0.0, GitVersion generates 1.0.1-branch0001 versions. I experimented a bit, and if I run it in master with next-version set to 1.0.0 and mode:MainLine, it will generate 1.0.0. However my build processes deploys the pre-release versions to a test environment, and I need them to be a semantically lower version than the 1.0.0 that will eventually be released.
Is this a bug in gitversion? Is there an additional configuration setting I'm missing? Some misunderstanding I have with how the tool operates?
The text was updated successfully, but these errors were encountered: