adamralph
commented
3 months ago @DavidBoike oooh this is an interesting one.
From the look of https://github.com/adamralph/minver/issues/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.
DavidBoike
Version(s)
5.0.0
To reproduce
Steps to reproduce the behaviour:
<MinVerMinimumMajorMinor>1.17</MinVerMinimumMajorMinor><MinVerTagPrefix>prefix-</MinVerTagPrefix>prefix-1.0.0Expected 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.