Provide a way to translate the PreReleaseLabel (alpha, beta etc) to a numeric value to avoid version collisions

[ruhullahshah]

Provides a way to translate the PreReleaseLabel to a numeric value in order to avoid version collisions across different branches. For example, a release branch created after "1.2.3-alpha.55" results in "1.2.3-beta.1" and thus e.g. "1.2.3-alpha.4" and "1.2.3-beta.4" would have the same file version: "1.2.3.4".

Related Issues 1145, 1366

[jbaehr]

What do you (and @BCSharp, @JakeGinnivan, @asbjornu) think about providing default values for the pre-release weight supporting the standard alpha->beta->final scheme? This PR offers a clean solution for those who know the problem, but it always requires additional configuration. I think the default configuration should be usable already, giving a consistent picture with the rest of the default configuration.
I'd vote for assigning a default weight to the default labels so that this feature offers additional benefit out of the box.

Now the question what to use as default weights. On Windows we have a 16-bit constraint we cannot do anything against. In addition, I'd like to have the weights as nice numbers in base-10, which allows easy back-mapping for humans. Next, I expect the majority of builds to come with alpha-labes, so I want to reserve roughly the half of the available number space for them. The other half can then be used for beta, (rc, as needed) and the final build. So here comes by proposal:

• alpha: pre-release weight = 0 (develop branch)
• beta: pre-release weight = 30_000 (hotfix and release branch)
• final, aka no pre-release label: pre-release weight = 60_000 (master, tags)

For special requirements there is enough room to fit release candidates after the beta, allow more then one "final build" or even to assign a non-zero offset for alpha-builds to make them "heavier" then CI-builds from feature branches. However, such things go far beyond an easy to understand default config.

[ruhullahshah]

@jbaehr I agree that providing a branch specific default pre-release-weight would be helpful. The scheme you proposed seems good to me but I would like to hear more from the maintainers ( @JakeGinnivan, @asbjornu) and @BCSharp on this and I will update the PR.

[BCSharp]

I have mixed thoughts about providing default non-zero values in this PS.

On one hand, it is nice to have a reasonable behaviour offered out-of-the box that the suggested defaults would provide.
On the other hand, I have concerns about changing anything automatically for users that do not have those values configured and maybe depend on the current behaviour. A change like that is better saved for a major version upgrade, accompanied with release notes.

In the end, I would not do it in this PR. The PR as is now is more likely to be accepted by the maintainers, (since it does not change anything on the current behaviour unless explicitly configured) and having it merged is way more important than sensible defaults.

[jbaehr]

@BCSharp My proposal about sensible defaults for the branch-specific pre-release-weight is not about changing existing behavior, it's only about improving this PR.
Note that the existing variable PreReleaseNumber continuous to exist, keeping its semantics. Only the newly introduced variable WeightedPreReleaseNumber is affected, and with a weight defaulting to zero both are equivalent.

I'm explicitly not proposing "{Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber}" as default for assembly-file-versioning-format, although this is exactly is required by Windows Installer. That would be a breaking change, indeed.

[BCSharp]

@jbaehr Yes, indeed. So in this case, it makes more sense to have reasonable defaults right from the beginning.

[asbjornu]

@ruhullahshah, sorry for my late input on this, but I agree with @jbaehr and @BCSharp in that reasonable defaults make a lot of sense. If you could add that and rebase this PR, I'd love to merge it and have it shipped as part of GitVersion 5.

[ruhullahshah]

@asbjornu I have updated the the PR with the requested changes.

[asbjornu]

@ruhullahshah, awesome, thanks!

@jbaehr and @BCSharp, do you agree with the defaults provided in the PR? If so, this is good to be merged as soon as the tests turn green.

[jbaehr]

My proposal for defaults ("alpha":0, "beta":30_000, "<non, aka final>":60_000) was based on the assumption that the prerelease number is reset whenever the next label is reached. This holds true for "beta", but recently I've observed that the final build (without a label) has a value of all commits since the last final in it's prerelease number. Given this fact, 60_000 would overflow the 16-bit if we have more then good 5000 commits since the last release.
If there is a strong reason for the prerelease-number-reset to behave differently for different labels, we have to adjust the defaults. If I've encountered a bug, those defaults are fine (and we need to hunt down the bug)

[ruhullahshah]

I suggest we decrease the defaults for <non, aka final> from 60,000 to 55,000 for now and then open a new PR for the observation reported by @jbaehr, if required. Also these are merely the defaults and can be tuned using the pre-release-weight.

[asbjornu]

@ruhullahshah, sounds good. Can you implement the decrease and do a rebase on HEAD of master so we get rid of the merge commits? 🙏

[ruhullahshah]

@asbjornu Done

[asbjornu]

Excellent, @ruhullahshah. But can you please repeat the rebase due to the merge of #1599? 😅

[ruhullahshah]

@asbjornu Done :D

[asbjornu]

🙏