[Improvement] RFC regarding the calculation of Base Versions

[franknarf8]

Description

I was facing a problem with GitVersion today (where the presence/absence of a release made the version of another branch jump around like crazy) and after some investigation, I understand that the resolution of a BaseVersionSource of a MergeMessage depends on the presence/absence of a release in the repository. (FixTheBaseVersionSourceOfMergeMessageStrategyIfReleaseBranchWasMergedAndDeleted)

That code was added to stop versions from jumping around when a release branch is deleted. (#1526)

But when I investigated further, I started wondering why we were not using the BaseVersionSource from Tags first, before relying on the BaseVersionSource if MergeMessage. (this is actually how I understood this doc at first : https://gitversion.net/docs/reference/version-sources)

Possible Implementation

This PR does just that and I would greatly appreciate your opinion about it, as there could be unforeseen drawbacks. : #2799

Drawbacks

As you'll be able to see in the unit tests, the version is calculated differently when merge commits are involved. e.g. if develop is at 1.1.2-alpha.2 and we merge in a feature/* branch with 10 commits, the new resulting version would be 1.1.2-alpha.3 instead of 1.1.2-alpha.12 (or 13), as the MergeCommit is counted as 1 commit only.

This the version always keeps increasing, so all is good on that side, but I fear that the projects that are already at higher versions would be greatly impacted, when their version would be sent backwards on a GitVersion update.

Thanks a lot for taking the time to read this!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.