Re: Plan for the 5.9 branch

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

dana wrote on Sun, 16 Feb 2020 20:47 -0600:
> On 16 Feb 2020, at 05:15, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > As to branching policy, in the future we should probably do things the
> > other way around; that is: in the run-up to the 5.9 release next year,
> > rather than stabilize on master and open a 5.10 branch for destabilizing
> > changes, we should open a 5.9 branch for stabilization and leave master
> > open to destabilizing changes.  
> 
> I like this. When we reach 'feature freeze' for 5.9, we branch off, only
> back-port important stuff from master, and then release 5.9 based on that
> branch. If we find any regressions or security bugs, we can back-port those
> fixes and release 5.9.1 or whatever.

Yes.

(When physically doing the commits to the two branches, I'm not sure if it'll be
easier to cherry-pick, or to commit to the 5.9 branch first and then to run
«git merge 5.9» in master.)

> Oliver pointed out before that nothing stops us from back-porting stuff and
> releasing patch versions now,

Indeed, there's nothing stopping us from creating a 5.8 branch right now, if
people are willing to maintain it.

> but i think the important thing is to have a
> standardised process for it. It makes the releases go smoothly, and it helps
> everyone make sense of the repo and the version history. And obv we'd document
> the process somewhere for anyone who might get confused.

I think even before documenting the process, we'll have to agree on
what the goal is and what the additional releases would contain.  Just bugfixes,
or also new features?  What degree of support/compatibility promises will they
come with — comparable to a -dev/-test release or to a regular release?  Etc.

> The main concern i've heard about it in the past is that maybe some of the
> devs don't have the bandwidth for the extra work, but ideally the back-ports
> would be infrequent, and presumably it'd fall on the RM to make sure nothing
> falls through the cracks
> 
> dana
>