rc/m commits in release or one-off branches?

[peel]

Do we need rc/m commits and tags within release branch? Maybe it's just easier to have them in new branches spun off release branch? It would be easier to clean up and has no interference with the main branch?

[benjben]

Usually we have one commit with the final version, and then additional commits for -rc/m. When -rc/m are validated, we just remove these commits and we merge.

[peel]

Sure, I get that. My question is whether that's something we want to continue to do. Or maybe we could consider separate rc branches that we can freely manage without much noise in PR and easier removal without rebasing. I'm fine with both, but branch-based flow seems easier on eyes and fingers.

[benjben]

Ah yes sorry. I'm fine with both too. Maybe I'm a bit in favor of keeping one PR, to have everything in one place. If we go with branches, I think that we should still have all the discussions related to -RC/M on the PR branch.

[peel]

My point is, that the RCs don't really contribute to the broad picture and are used as "developer snapshot". The actual changes and discussions are in the main branch whereas rcs are just a deploy-to-check snapshots. I find them muddying the original PR and causing more harm than benefits in terms of PR contents.

Anything works for me, just trying to understand the reasoning.

[chuwy]

Sorry guys I'm bit rusty when it comes to git flow, but will our git flow transition (assuming its happeneing somewhere in 2020) affect this decision?

Also @peel, just to understand the proposed flow better. You're saying we can do the release/x.y.z branch, then once everything is ready branch off the release/x.y.z/rc1. Then if we find a bug/thing-to-fix we branch off the release/x.y.z/rc2?

[peel]

I do think rcs are one of the unresolved issues. They usually are just tags on normal commits introducing things (ie. "fix unit tests" tagged with "v1.1.1"). With our very specific 1:1:1 rule it won't be really possible as there needs to be a separate commit that bumps the version and as the commit vanishes from the flow I'd recommend exactly the approach you mentioned. I'd fix the bug within the original branch for less clutter and then use a rc2 branch and remove the rc1.

[chuwy]

I think there are some misunderstandings about how the current system actually works:

They usually are just tags on normal commits

They're always tags on the very top temporary commit

ie. "fix unit tests" tagged with "v1.1.1"

We should never tag commits like that with final

There are several important assumptions that we need to involve:

• Branch is a dev workflow. For feature (PR) or release. It is owned by an engineer.
• Tag (RC) is a snapshot of the worfklow that can be materialized, tested and become a release.

Tags are always preserved in a commit history. At any point in time engineer is able to see that on a pipeline A we have an artifact B-rc2 and find out how is that different from the final version. A branch will be just vanished and they will never result in PRs.

separate rc branches that we can freely manage without much noise in PR and easier removal without rebasing

The thing is that we want this noise in PR. This is where discussion happens on what goes into an RC, why it is necessary and when it was published.

[peel]

The thing is that we want this noise in PR. This is where discussion happens on what goes into an RC, why it is necessary and when it was published.

✅