Finalizing the configuration of GitFlow and GitHubFlow workflow and align with the Mainline version strategy

[HHobeck]

Description

Finalizing the configuration of GitFlow and GitHubFlow workflow and align with the Mainline version strategy. See:

• [Improvement]: Finalizing the configuration of GitFlow and GitHubFlow workflow and align with the Mainline version strategy #4005
• [Bug] GitVersionTask: VersionSource is set to wrong tag #2394
• [Improvement] Increment version as per source branch  #3689

Close #4005
Close #2394
Close #3689

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

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.

[HHobeck]

I think conventionalcommits.org has problems with it's certficate:

[HHobeck]

The artefacts tests are failing... Maybe because of my changes!? Probably we need to change the assertion condition.

[asbjornu]

Should release branches really increment by default?

[HHobeck]

Actually good point. I thought it would be a good idea to have this in place to do the following:

What would be the argument against the usage of release/next and the behavior of incrementing by default?

[asbjornu]

I think that's fine as a possibility, but perhaps not as the default mode of operation? I think the defaults should adhere to the established norms for the supported workflows, in which release branches are named by the upcoming version number.

[HHobeck]

I think that's fine as a possibility, but perhaps not as the default mode of operation? I think the defaults should adhere to the established norms for the supported workflows, in which release branches are named by the upcoming version number.

I'm not sure if you see my change in the right light. This change is not about changing any default behavior rather than handle the case when the users are not specifying a dedicated version like release/2.2.1. You say that we should consider the established norm. But what is the established norm in case of specifying release/next? If it is like you say: Why do we not set the regular expression to ^releases?[/-](?<BranchName>\d+\.\d+\.\d+.*) and force the user to use a version number?

Finally my motivation is not about changing the default behavior but making the behavior of git flow workflow better in this scenario no version number is present in the release branch. Is this not a valid improvement especially if it has no disadvantages (It is additiv)!?

Please see the following sequence diagram when specifying a version number which applies with this configuration as well:

[HHobeck]

@asbjornu: Can you please answer the question or give me some arguments why we should not handle the case for release branches with no version number?

[asbjornu]

I'm not against handling the case for release branches with no version number, but won't this change make that the default?

[HHobeck]

Actually like you see in the both sequence diagrams I provided previously it will not change the default behavior except in one case:

Let's say you have a tag 1.0.0 on main and branch from main to release/1.0.1 branch then the next version number will be 1.1.0. But in my opinion that is okay because in the gitflow workflow you have an addition IsRelease branch configuration with name hotfix. If you want the 1.0.1 as a next version you need to branch to hotfix/1.0.1 or hotfix/next and not release. In githubflow workflow it is not a problem because there the increment is set to patch for release branch.

I don't like the default behavior when using release/next because it will be resulting in 1.0.0 which is obviously wrong. Does it make sense?

[asbjornu]

Yes, that makes sense. Sounds like a reasonable compromise to me. 👍🏼

[HHobeck]

@asbjornu @arturcic Please proceed and merge this pull request to main.

[mergify]

Thank you @HHobeck for your contribution!