[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: Staging Branches [REVISED]
From:       Peter_Kümmel <syntheticpp () gmx ! net>
Date:       2016-04-18 21:02:23
Message-ID: F83CD447-7793-4B3D-92F4-0757502E72E9 () gmx ! net
[Download RAW message or body]

Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck <rgheck@lyx.org>:
>On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
><syntheticpp@gmx.net>:
>>> I also think these branches are overkill.
>>>
>>> I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>>>
>>> 2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>>>
>>> Similar to 
>>> https://wiki.qt.io/Branch_Guidelines
>>>
>>> Peter
>> We should already be on 2.2 and not on master, which is the future:
>2.3 
>
>We discussed this sort of option: Branch 2.2.x now and continue
>development towards 2.2.0 there. Then development targeted at 2.3 can
>continue in master. But most people didn't like this option. Most
>importantly, Scott didn't like it, or didn't feel comfortable with it,
>and it's his call.
>
>So master is still what will become 2.2.0, and it is closed except for
>absolutely essential fixes. But people wanted to be able to continue
>development, so that's why we have 2.3-staging.
>
>The other two 2.2.x-staging branches are entirely for book-keeping
>purposes. It is just easier for me to have the various fixes that are
>intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>track of them via milestones or keywords or whatever in trac. It's also
>easier for people to backport these fixes around the same time they did
>them than to do it weeks or months later.
>
>We're not really "think[ing] about four stable releases in parallel",
>and certainly I do not expect that the staging branches are going to
>get
>any kind of testing. Once 2.2.x is created, it will get testing, and at
>that point 2.2.1-staging will be merged into it, and then will politely
>disappear. Same, eventually, for 2.2.2-staging.
>
>Richard

But why are there fixes which should go only into 2.2.2 and not into an unreleased 2.2.1? 
Peter
[prev in list] [next in list] [prev in thread] [next in thread]