On 04/12/2016 04:42 AM, Jean-Marc Lasgouttes wrote:
> Le 12/04/2016 04:09, Richard Heck a écrit :
>> I propose to create a 2.3.staging branch so development can proceed. We
>> did this with this 2.1 cycle. Alternatively, we could create a
>> 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have
>> full control over that.
>
> Why don't we branch 2.2.x right now and resume working on master? Do
> you think that the amount of work until 2.2.0 is so large that this
> would entail work duplication?

I thought about that, too, but was reluctant to suggest it for fear of
starting a flame war. But it would be a natural thing to do at this point.

Scott, do you have views about this?

> I would like also to see a strategy for 2.2.1. Do we reserve this
> milestone for urgent fixes and keep 2.2.2 for more mundane backports?
> Or do we treat it just like any other stable release.

I guess my strategy would be to allow anything that is completley safe
and maybe to hold onto patches that are a bit less so. If it looks like
we don't need a "quick" release of 2.2.1, then we can include those
other patches. If we do need such a release, I won't include them.

Practically, I'd plan to create 2.2.1-staging, so that things that will
go to 2.2.1 don't get forgotten, and also some other branch for the
"held" patches. All just a way to keep track of things. Branches in git
are cheap.

FYI, I just created a 2.2.2 milestone for this sort of purpose.

> Finally, there are a few fixes that will not be in 2.2.0 that I would
> like to backport for 2.1.5. Is this possible? A typical example is
>   http://www.lyx.org/trac/ticket/10048

I believe we have done this before, i.e., last time, so you can go
ahead. I'd also be happy to have the patch for 10063 in 2.1.5. But we
should wait to do any of that until we're sure what we're doing
otherwise, e.g., until 2.2.x exists.

Richard


Reply via email to