[mtzet]

I agree about being pragmatic and doing what the business needs are at the moment!

But that's also why I argue for having less process up front and creating it as needed. The master branch exists solely for the aesthetic reason of having a linear history from version to version. This is obviously incompatible with a non-linear version history.

Simplify the initial process by getting rid of master and tagging directly on the release branch.

In fact, the merge from release branch to master is a bit suspicious. I'd expect the contents of the merge to be precisely the contents of the release branch, regardless of what was on master previously. If not, what am I releasing?

[horsawlarway]

Yup - I agree. I think we'd get along just fine :)

It can be nice to generate release notes from the commits in the merge between the latest release and master, but you can honestly get the same info in a variety of ways (and depending on the team - it may be particularly noisy)

Basically - I think as long as tagging is happening somewhere, and that tag reflects the actual code released, I don't really have a strong preference on the branching around the process. Sort of an implementation detail that doesn't matter that much.