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.
From investigating the build to ensure that tagging produces correctly packaged version, I found that the GitVersion tool added a lot of complexity that made it hard to reason about what versions would be produced in the build for a given tag (or lack of tag).
Having done some research, I feel that MinVer makes things a lot simpler and easy to reason about, so this PR drops GitVersion in favour of MinVer and its MSBuild integration.
I also propose using its default pre-release label convention, which roughly matches the versioning of .NET itself, so
a.b.c-(alpha|beta).d
, so our first alpha would be8.0.0-alpha.1
and we can just increment that number when we tag as we go if there are further alphas.The TL:DR effect of the tool change are:
major.minor
version is now controlled through theMinVerMinimumMajorMinor
MSBuild property.alpha
.x.0.0.0
wherex
is the major version.pr.{number}.{build}
.8.0.0-alpha.1
? Create a release with a tag called that.8.0.0
? Create a release with a tag called that.Testing
I tested the changes in this PR by creating a new repository seeded from 59fd86b, and then tweaking the build to make the feedback loop faster by turning off the tests and non-Windows OSs and removing the signing and NuGet push steps (as they wouldn't work anyway).
I then made various changes to the repo to simulate development work, PRs etc, and created some releases. The Polly package versions created through the tests can be found here.
The version behaviour from the different activities are shown below:
main
main
main
after PR8.0.0-alpha.1
main
after tag8.0.0-alpha.2
8.0.0
8.0.0
main
after PR8.0.1
main
after tagSummary of changes
Resolves #1274.