@jbaehr @asbjornu

I have created an initial proposal for addressing issue #1994 and added a failing unit test for the type TaggedCommitVersionStrategy. I have not set up the config for the unit test yet. Once the config is finalised, I will proceed with the feature construction and add appropriate config options to the unit test and to some integration tests. Please let me know your thoughts about the proposal.

While don't fully understand the use cases of #1994 and #1600 (and, to be honest, I haven't dug deeply into the later), I can't really comment on the tag-config proposal. Apart from finding an additional, nested file-versioning-format a bit odd; What does it offer opposed to the global assembly-file-versioning-format with the standard WeightedPreReleaseNumber?

Anyway, I propose to go for a simpler approach first, just enough for the vanilla gitflow use case, where you only tag final versions. Simply defining a static default pre-release weight for tags should be enough for preventing the WeightedPreReleaseNumber to be null on builds from tagged commits. This default should be as high as possible, as there is no semver "larger" than the final build. And "commits since version source" should be always zero, per definition, else your current commit is not the tagged commit, ergo a branch config should apply. For Windows we have 16 bit for this, thus $2^16 - 1$ would give a good value. Or 60000, for those preferring human-readable numbers (programmers are not "normal" humans).

So either we can go for a new top-level config key, a simple scalar. Or, in the same spirit as the branch config something like

tags:
  default:
    pre-release-weight: 60000

Later, this can still be extend with different named tag configs, with regex matching and extracted pre-release labels, what ever...

If your proposed solution is sufficient, it's definitely the simplest one to implement, maintain and document, @jbaehr. Thoughts, @ruhullahshah?

@jbaehr, @asbjornu

• My proposal was aimed to be a more general solution, with GitFlow being a special case, wherein under pre-release-label-weights one could specify default: 60000 for the final release build.
• file-versioning-format: "v{Major}.{Minor}.{Patch}.{TagWeightedPreReleaseNumber}" was aimed at instructing the TaggedCommitVersionStrategy as to how to construct the version numbers out of tags, for instance 1.0.0-alpha would get mapped to 1.0.0.10000
• However, I see @jbaehr 's point and it indeed simplifies the implementation if we are targeting GitFlow only for now. Also, it serves as a good starting point, as already mentioned by @jbaehr, for generalizing the implementation.
• I will take up the proposal made by @jbaehr and implement it.

Sounds good, @ruhullahshah! Looking forward to seeing the implementation.

@asbjornu I have added the changes that I believe are minimal and necessary to address the issues described by users in #1994.

Sounds and looks great, @ruhullahshah! Could you give this a quick review too, @jbaehr? A rebase on the HEAD of master would probably also be a good idea. :)

@ruhullahshah thanks for your work!

I only question the "0" default for the tag-pre-release-weight. In my eyes (as motivated in my first comment) the value should be high, to make sense. As the WeightedPreReleaseNumber was previously undefined/empty/null, we don't need zero for backward compatibility, either. Instead, the default here should fit with the defaults from the branch configurations, see #1433, i.e. 60_000.

@jbaehr You are welcome.

I agree, a default weight of 60000 makes more sense. That way a user using the GitFlow branching model might not even need to specify the value in the configuration. I have updated the PR for the same.

@asbjornu Could we ship this now, do not want to rebase anymore :P ?

Thank you so much for your work on this @ruhullahshah, and for your valuable input @jbaehr! 🙏

@asbjornu You are welcome!