On 04/18/2016 05:02 PM, Peter Kümmel wrote: > Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck <[email protected]>: >> On 04/18/2016 04:32 PM, Peter Kümmel wrote: >>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" >> <[email protected]>: >>>> 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?
Because the plan (discussed in another thread) is currently to reserve 2.2.1, for the time being, only for serious bugs that emerge shortly after release, if any do. I.e., 2.2.1 may be released very shortly after 2.2.0, and too soon for anything to get much testing. There are bugs for which we now have fixes that aren't appropriate for 2.2.1, under that plan, but will go into 2.2.x eventually, i.e., into 2.2.2. If things go better than expected, and we don't need to do a "quick" release of 2.2.1, then we can merge 2.2.2-staging into 2.2.x as well and release all that as 2.2.1. Richard
