Opt out from autoincrement feature (multiple projects in a single repo)

[TimTK17]

Use case(s)

There are times when I would like to opt out from autoincrementing feature completely and use tags by hand only.

Description

While something similar has already been asked before (#500, #519, #616), I would like to raise this issue again.

Standard scenario. Let's say I have two projects in a single repo: Main and Extension. Extension depends on Main. I version these projects independently with MinVerTagPrefix property set for each project (main- and ext-). Let's say latest commit tags are main-2.0.1 and ext-1.0.1.

Now if I commit something to Extension's folder with no change to the Main folder, tag the commit with ext-1.0.2, pack the Extension project, then the resulting Extension.nuspec will reference incremenented version of Main (2.0.2-alpha.0.1), which is very much an expected behavior consistent with the docs. But the Main package hasn't changed, and the desired Main's version would still be 2.0.1.

What I would want to do is to have something like MinVerAutoIncrement set to 'none' and version everything manually - without autoincrementing, by specified tags only, as they are. In this case, any package version could be obtained from the latest tag (with the corresponding prefix) anywhere deep in commit history. So the idea is to be able to completely turn autoincrement or any automated behaviour off. If for some reason I commit changes in two folders simultaneously, I would create two tags on the commit, say, main-2.0.2 and ext-1.0.2.

In #616, @adamralph suggested MinVerLockToLastTag property, but was 'struggling to see much benefit over manual versioning with the property'. I agree that benefit is not much, but still is. As @adamralph himself advocates using tags only, using Version properties would be an issue. The very idea of 'tagged' versioning in MinVer, and which I loved, is to use commit tags for both git and package versioning. And the commit tag is the only source of truth. I can roll back to any version given a tag. But there's no convenient way to roll back if the version is specified in a file as a Version property.

As suggested by @adamralph in #500 (comment), I can solve this by adding and removing MinVerVersionOverride in the Main project, but frankly it's an overkill :) and it would require changing and committing Main.csproj twice, rendering MinVer useless.

[adamralph]

@TimTK17 sorry for the radio silence. I see the use case. I'm trying to think of a reason not to add this feature but I haven't found one so far.

[adamralph]

@TimTK17 after more thought, I'm happy to go ahead and add this to MinVer 3.1.0. I don't need it myself, but it's a low risk, low maintenance feature. I'm happy to add it myself, but before I do—would you like to send a PR?

I suggest we name the new property MinVerIgnoreHeight (and the new CLI option -i|--ignore-height). That way, it can default to false, and the name conveys that everything happens as normal, with the exception of factoring height into the version. The implementation will have to make the call to Version.Height() conditional on the property (or CLI option).

[adamralph]

FYI I've started work on this in #693

[adamralph]

@TimTK17 thanks for raising this issue.

For housekeeping purposes, I'm replacing it with #697, which is formatted to be more suitable for linking from the change log.

[TimTK17]

@adamralph sorry, I was away for a while. It is indeed solved now. Thank you very much!