-
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
Refactor next version calculator (get rid of taggedSemanticVersion
)
#3244
Refactor next version calculator (get rid of taggedSemanticVersion
)
#3244
Conversation
I like your refactoring Alex. 👍 Good work. When I execute the unit tests I got some NullReferenceExceptions. |
c95b521
to
059375f
Compare
I fixed failing unit tests and they pass locally but I still have issues with some CI jobs:
|
0977561
to
c718ee0
Compare
@HHobeck , all failing tests are due to the .NET 7 instability on ARM. Can this PR be merged or it needs some corrections? |
c718ee0
to
e7e7be5
Compare
@AlexPykavy - can you please fix the warnings as well? https://github.com/GitTools/GitVersion/actions/runs/3577000238 |
e7e7be5
to
20a8fe7
Compare
Fixed, but I'm not sure about adding |
This might be also possible: if (Context.CurrentCommitTaggedVersion?.CompareTo(semver) == 0)
{
...
} |
src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core/VersionCalculation/NextVersionCalculator.cs
Outdated
Show resolved
Hide resolved
20a8fe7
to
0e6554e
Compare
4a3d092
to
e9edd32
Compare
@arturcic: May I ask you is it possible to go away from .net standard? It makes no sense in my opinion if we move to .net 6 and 7 or I'm wrong? It would be nice to use the Init Only Setters feature. |
Honestly I was considering that. We need to check the libgit2sharp if can pe used in this case |
Forget my post. I haven't seen the indirect dependency via GitVersion.LibGit2Sharp project |
@AlexPykavy Could you please take a look on all references of the property
|
From my point of view the next refactoring steps are the following:
What do you think? (Maybe in a separate PR) |
@HHobeck I can take this one in a separate PR:
As for the others, you can work on them if you have a bit of time |
e9edd32
to
85603d4
Compare
Done if I understood you correctly :) |
85603d4
to
9b19750
Compare
@HHobeck, updated. You got me there: I forgot about checking |
Okay thank your very much @AlexPykavy for your work!! :) From my point of view the PR can be merged to main. @arturcic @asbjornu |
I'm not sure why the second tests fails. Maybe you can help me? @arturcic, @AlexPykavy Is it because of the refactoring in the PR? This two tests are new and comming from the main branch: Message: |
…g test Because release branch has 'beta' prefix configured.
To improve readability.
To make the method logic more understandable.
Because `this.mainlineVersionCalculator.FindMainlineModeVersion(nextVersion.BaseVersion)` method calculates BuildMetaData on its own.
Change next version calculator to act according to the next algorithm: 1. Calculate next version candidate based on the base one 2. Look for the latest `PreReleaseTag` matching Major, Minor and Patch of the next version candidate. 3. Append the `PreReleaseTag`, if found, to the next version candidate. 4. Compare the next version candidate with `Context.CurrentCommitTaggedVersion` including the `PreReleaseTag` comparison. 5. Increment the `PreReleaseTag` of the next version candidate if versions mismatch. 6. Return the next version candidate.
…lable type Because they are always set in SemanticVersion's constructor. They can be null only if explicitly set by the client of the class and there are plans to forbid this functionality.
22fa5fc
to
5767382
Compare
Fixed by considering empty |
Thank you @AlexPykavy for your contribution! |
🎉 This issue has been resolved in version 6.0.0-beta.1 🎉 Your GitReleaseManager bot 📦🚀 |
Suggest to review by commits :) I tried to make them as atomic as possible.
Description
Minor changes:
Change next version calculator to act according to the next algorithm:
PreReleaseTag
matching Major, Minor and Patch of the next version candidate.PreReleaseTag
, if found, to the next version candidate.Context.CurrentCommitTaggedVersion
including thePreReleaseTag
comparison.PreReleaseTag
of the next version candidate if versions mismatch.Related Issue
Motivation and Context
I found
NextVersionCalculator
logic complicated and decided to simplify it.How Has This Been Tested?
By running all existing tests.
Screenshots (if appropriate):
Checklist: