Re: Plan for the 5.9 branch

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

dana wrote on Tue, 18 Feb 2020 13:40 -0600:
> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > 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?  
> 
> Right. All i'm really worried about personally are fixes for security issues
> and the type of regressions we normally correct in .1 releases.

For this sort of thing I think we have two options:

1. Release 5.8.1 from master, including the several small changes that
have already been pushed.

2. Create a new branch off the 5.8 tag, fix the security issue or
regression on that branch, and release _that_ as 5.8.1.

> Beyond that, maybe stuff like trivial completion updates could go in if we're
> planning a patch release anyway — that's what we've done lately with .1
> releases — but i don't think it's important and i'm not suggesting that we go
> out of our way for them.

*nod*

> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > What degree of support/compatibility promises will they
> > come with — comparable to a -dev/-test release or to a regular release?  Etc.  
> 
> Re: compatibility, as a rule i would suggest that patch releases under this
> system should not contain anything that Debian/Ubuntu wouldn't be comfortable
> pulling into one of their (non-rolling) releases. Maybe that's slightly too
> strict in practice, but i think that's a reasonable goal at least.
> 

Let's try to reach a self-contained definition.  How about the
following blacklist rule: backported changes shouldn't be destabilizing
or invasive and shouldn't introduce new APIs?  Or a whitelist rule:
changes should fix a bug or add a small/localized feature, while also
meeting the aforementioned (blacklist) criteria?

> Re: support, i'm not sure i even know what promises we make for stable
> releases now, lol
> 
> dana
>