3 ms·
I never felt the need/use for reintegrating release branches. I just fork those off so that new developments with more unstable code can continue in the mainlin
by alkonaut 3y ago
I never felt the need/use for reintegrating release branches. I just fork those off so that new developments with more unstable code can continue in the mainline. Any hotfixes in the release branch then must be applied both to the release branch and the mainline, but I don’t think that’s a drawback. Usually it’s a workaround in the release branch but a more thorough refactoring in the mainline to solve the issue long term.
As an added bonus you can have multiple release branches for 1.0 and 2.0 at the same time, or even forked release branches where 1.1 is forked from 1.0 if necessary.
- j4yav 3y agoYou have multiple major release branches, multiple dot release branches related to each of these, and hot fix branches for any live ones and you aren’t running into merge issues? I agree it’s easy to make lots of forks but at some point changes you made in the last hotfix for a 1.1 release has to find its way to 2.3 right?
- 000ooo000 3y agoA worthwhile distinction might be the kind of applications under these branching strategies; web apps typically only have one live version which avoids the problems you've mentioned.
- j4yav 3y agoIf you only have one live version then I’m even more confused why you’d need all these different major and minor version numbers and their hotfixes to be in simultaneous development.