Finalizing the configuration of GitFlow and GitHubFlow workflow and align with the Mainline version strategy#4009
Conversation
|
I think conventionalcommits.org has problems with it's certficate:
|
|
The artefacts tests are failing... Maybe because of my changes!? Probably we need to change the assertion condition. |
| mode: ManualDeployment | ||
| label: beta | ||
| increment: None | ||
| increment: Minor |
There was a problem hiding this comment.
Should release branches really increment by default?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
releasebranches 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:
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
I'm not against handling the case for release branches with no version number, but won't this change make that the default?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Yes, that makes sense. Sounds like a reasonable compromise to me. 👍🏼
18a6c3b to
a2344cc
Compare
…lign with the Mainline version strategy
58beae9 to
83203a8
Compare
|
Thank you @HHobeck for your contribution! |
Description
Finalizing the configuration of GitFlow and GitHubFlow workflow and align with the Mainline version strategy. See:
Close #4005
Close #2394
Close #3689
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Checklist: