5 ms·
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
by mtzet 4y ago
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 4y agoYup - 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.