Next pre-release versions when the previous pre-release versions are tagged

[0xced]

First of all, thanks for MinVer, it's an excellent tool!

I'm having trouble figuring out how to use MinVer for computing pre-release versions when previous pre-releases are tagged.

Let's explain with an example. I have set MinVerMinimumMajorMinor to 1.0 in my project file. The repository does not have any tag yet. I use MinVer and it produces the following version: 1.1.0-alpha.0.104. Then a create a GitHub release with a GitHub action. This adds the 1.1.0-alpha.0.104 tag to the repository.

Now, one commit later, MinVer finds this tag and the next produced version is 1.1.0-alpha.0.104.1. This matches the documentation but I'd expect MinVer to produce version 1.1.0-alpha.0.105 instead. This problem grows as you add pre-release tags since it will always append .height to the previous tag instead of incrementing the height of the previous tag. And 12 commits later you'll have something like 1.1.0-alpha.0.104.1.6.2.3 instead of 1.1.0-alpha.0.116.

So here is my question: Is there a way to configure the current MinVer (either version 2.4.0 or 2.5.0-alpha.1) to produce a more sensible version? If not, would you accept a pull request modifying the current behavior?

[0xced]

This was easier to fix than I expected so I went with a pull request: #489

[AshleighAdams]

Just wondering, have you thought about using GitVersion?

It's my understanding GitVersion is better suited for continuous deploy workflows (where deploys can auto tag), whereas MinVer focuses on continuous delivery, where deploys/releases are triggered by you tagging it. Your change is a breaking change (albeit minor) and though I can't speak for @adamralph, I suspect it may be out of scope for MinVer?

[0xced]

I have tried many versioning strategies over the years, including GitVersion, but MinVer is my favorite. I really like the way it works by having the tag as source of truth for the version and fallback to computing a pre-release version if there's no tag.

I think that this particular scenario where the pre-release versions are tagged after being computed was simply overlooked. I was able to fix the behaviour without breaking any existing test. I had to add a new test scenario to make sure the height is computed in a more sensible way in presence of already tagged pre-release versions.

Now let's see what Adam thinks…

[adamralph]

@0xced MinVer is working as expected. Versions with height are not intended for release. As @AshleighAdams says, MinVer is designed for "tag before release" workflows. Given your example, I would expect your first alpha to be tagged 1.0.0-alpha.1. Subsequent commits will have height added. Then when you are ready to release your second alpha, you would tag it 1.0.0-alpha.2, etc. Then you would graduate your tags to beta, RC, RTM, etc.

[nosalan]

I had the same observation as @0xced. We use trunk based development and it's nice to have pre-release tagging on main and non pre-release on realease branches. minver starts a new hegiht instead of summing to the one found on the nearest tag. I disagree that introducing this behavior to minver would be a breaking change because it could be controled via switch. Actual behavior is of course consistent with its design and generally it's a fantastic tool. I ended up summing these *.1.6.1.1 manually and tagging with sum to workaround this.

[adamralph]

I don't understand what you mean by "summing".

[nosalan]

1.1.0-alpha.0.104.1.6.2.3 -> 1.1.0-alpha.0.116

[adamralph]

Where does 1.1.0-alpha.0.104.1.6.2.3 come from?

[nosalan]

It was an example. Generally it occurs when I use minver to generate version and the nearest existing tag was a pre-release one. It adds .height at the end when in that situation. Cli command used to generate version: minver -v e. Example, not the same exact tag but to demonstrate the situation:

As to our git strategy we only use main branch (trunk based development) and tagging commits with such prerelease tags. I hoped that minver would just increase the last height counter, so referencing this example, the tags would be:
1.1.0-alpha.0.1.3->1.1.0-alpha.0.4
1.1.0-alpha.0.1.3.4 ->1.1.0-alpha.0.8
1.1.0-alpha.0.1.3.4.1 -> 1.1.0-alpha.0.9
So the summing I'm doing manually is simply adding the heights.

[adamralph]

Why do you have a 1.1.0-alpha.0.1 tag? I would expect that to be 1.1.0-alpha.1 (your first alpha release). The next tag would be 1.1.0-alpha.2, and the next one 1.1.0-alpha.3.

You appear to be using the version calculated by MinVer to create a tag. That's the reverse of how MinVer is designed to work. It is designed for a tag first approach. I.e. you want to release, so you first tag, then build, then release. The versions in between tags (those which have height), are not intended for release. Height is added to them only to distinguish the artifacts which those builds produce, FWIW.