one branch per maintenance version?

[David Disseldorp]

Hi Metze,

On Sat, 27 Jan 2018 23:12:50 +0100, Stefan Metzmacher wrote:

> Hi David,
> 
> > One thing I've never quite understood, and still find a bit cumbersome
> > is the use of two git branches per maintenance release: one "-test"
> > branch and one "-stable" branch.
> > 
> > IIUC, the maintenance process includes staging new bug fixes in the
> > "-test" branch until a point release is done. The point release process
> > involves adding a release notes commit, tagging it, and moving the
> > "-stable" branch up to the latest tag.
> > 
> > Given that we're pretty strict regarding what makes it into a
> > maintenance branch, and we don't play any games with rebase/reset,
> > couldn't we just drop the "-stable" branch, and just continue to stage
> > changes in  "-test" (renamed to e.g. vX.Y-maint) until a point release
> > tag "blesses" a given state as stable?  
> 
> Why? There's no real overhead in having the stable branch.
> If you don't want to use it just ignore it:-)

I try to ignore them, but they're a bit of an eyesore ;-)
Aside from the unnecessary extra state, I think it's a bit confusing for
newcomers to the maintenance process - e.g. "which of the two branches
should I use as the base for my bug-fix?"

> I often use the stable branch for reproducing customer problems.
> 
> Some customers also regularly rebase their product branches on
> the stable.

A (point release) tag can just as easily be used for local branching and
rebasing as a remote branch. I don't see any difference to these
workflows if we were to use a single branch alongside release tags.

> The stable branch is also used to create security releases,
> where we just want to release the minimal fixes.

Okay, do you mean that in the past we've collected regular maintenance
bugfix commits in the -test branch, and then later decided to do a quick
security release from the -stable branch by only applying the security
fixes to the previous release tag? I agree that this might be a reason
to keep the current double branch workflow.

Cheers, David