Tagged version not used as version when MinVerMinimumMajorMinor is higher
DavidBoike opened this issue · 2 comments
Version(s)
5.0.0
To reproduce
Steps to reproduce the behaviour:
- In a project file:
- Set
<MinVerMinimumMajorMinor>1.17</MinVerMinimumMajorMinor> - Set
<MinVerTagPrefix>prefix-</MinVerTagPrefix>
- Set
- Tag
prefix-1.0.0
Expected behaviour
According to How it works documentation, since it says "If the current commit has a version tag…The version is used as-is" I expect the version to be 1.0.0.
Actual behaviour
Build output is versioned 1.17.0-alpha.0.
Workarounds
I removed MinVerMinimumMajorMinor.
Additional context
The tag may have nothing to do with it but that's currently what I'm doing when I observe the problem.
I always thought the overriding principle of MinVer was a direct tag wins, always, and that the minimum version was only evaluated for commits that aren't directly tagged. It may be that "respecting" the minimum version is a design choice, but then the docs should be updated to reflect that.
@DavidBoike oooh this is an interesting one.
From the look of #63 it seems that it was a deliberate design choice to have MinVerMinimumMajorMinor override lower versioned tags:
If no tag is found with a higher version...
But after giving it some thought, I think your proposal of making the tag win probably makes more sense. After all, MinVerMinimumMajorMinor is provided as way to say: future dev work on this branch is for version x.y, rather than patches or minors on the previous version. It seems reasonable for someone to later decide that a commit on the branch is actually a patch or minor on the previous version, and tags the commit as such and expects that version to pop out.
I think this issue should probably be reframed as a (breaking) enhancement though, since I believe the current behaviour is by design, even if the docs imply something else. I can do that later unless you beat me to it.
Reframed as a breaking enhancement in #999