Adding Merge Commit Version Strategy

[Fenikkusu]

Description

I'm posting this as a draft to get eyes on it and see if it's something to continue working on or not. Fair Warning: It's been a long time since I've worked with C#, so likely something I'm missing here. There may be someone else that wants/needs to pick it up from here.

This is my attempt at introducing an alternative strategy for identifying the version based on version names after the merger. The strategy works by looping through all the commits, looking for merges and/or tags. If it finds a merge branch, it then uses the source branch name in collaboration with the branch configuration to determine the version that the branch should have generated.

If it finds a tag, it uses it for a reset to the current version. By doing this, it allows for situations where a tag is resetting the version and/or a branch was merged in that normally should have incremented the version, but it was unintentional or incorrect.

Given the merged commit history of:

• hotfix/a
• hotfix/b
• tag 1.0.0
• feature/c
• feature/d
• unstable/e
• tag 1.1.0

And the config of:

• hotfix: Patch
• feature: Minor
• unstable: Major

The version would be detected as:

• 0.1.1
• 0.1.2
• 1.0.0
• 1.1.0
• 1.2.0
• 2.0.0
• 1.1.0

Leaving you with a final version of 1.1.0.

Related Issue

#4624
#4433

Motivation and Context

I am working in an environment where there are over 90 team members all wanting to mark a feature or release as their own. This is creating a scenario where, many times, people are scratching their heads about what version a feature should go into or what version a release should be flagged. To circumvent this, I am trying to push to get Semantic Versioning adopted, but I need to be able to get the version post-merge, without any involvement from any of the developers requiring them to tag releases or similar. Once a branch is merged, the source branch name should dictate the new version name. By doing this, the developers need only be concerned with the basic rules of whether it's a feature or not, and of if it's backward compatible or not.

How Has This Been Tested?

I ran the changes against another project that has the same "post-merge" setup as discussed above. No automated testing has been done yet.

Screenshots (if appropriate):

N/A

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.