Re: Plan for the 5.9 branch

[dana <dana@xxxxxxx>]

On 18 Feb 2020, at 14:44, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> Each proposed change goes on its own branch created from master.  This
> is rebased on master if necessary before merging with other changes.

We do this part where i work as well. The topic-branch thing seems to be most
beneficial when you're using those branches for QA, or when you're using
something like GitLab for reviews and/or MRs; in a system like this where we
just e-mail patches around anyway, i guess it doesn't make a huge difference
outside of each dev's personal work-flow

On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> 1. Release 5.8.1 from master, including the several small changes that
> have already been pushed.

Which is what we've been doing, and it's fine, as long as master hasn't moved
on, or it's not preventing it from doing so. I'm definitely not concerned if a
few documentation/test/completion improvements make it into a .1

On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> 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?

Both of those seem unobjectionable to me

On 19 Feb 2020, at 04:32, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Now, suppose we add a new feature in March, then in April make
> a release off master that ships that feature, and then in May we find
> a bug in that feature.  Are we allowed to break compatibility with the
> the April version of the feature in order to fix the bug?

Are the considerations in this scenario any different from how it is now?
Maybe i'm not following. Either way, in general, i agree with what Bart said

dana