Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" <syntheti...@gmx.net>: >Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum ><georg.b...@post.rwth-aachen.de>: >>Richard Heck wrote: >> >>> We now have three staging branches. These are: >>> >>> 2.3-staging >>> 2.2.1-staging >>> 2.2.2-staging >> >>That makes 5 active branches in total (please correct me if I >>misunderstood >>something): >> >>2.1.x => will become 2.1.5 >>master => will become 2.2.0 >>2.2.1-staging => will become 2.2.1 >>2.2.2-staging => will become 2.2.2 >>2.3-staging => will become 2.3.0 >> >>Am I the only one who thinks that this is too much? IMHO this results >>in a >>lot of additional book keeping work that eats from our valuable >>resources. >>In addition, there are the trac keyword problems. Currently it is not >>possible to map these branches to trac, if we wanted to do that we'd >>need >>three additional keywords for the staging branches. If we do not add >>these >>keywords then bugs might be closed for the wrong milestone and/or we >>need >>manual work to find out from trac whether a particular bug will be >>fixed >>e.g. for 2.2.1 or not. >> >>Such a structure is good for large organizations. It does not make >>sense for >>such a small group of part time developers like us IMHO. We do not >have >>the >>resources to think about four stable releases in parallel. IMHO we >>should >>concentrate on one branch for 2.2.0 and one for 2.3 development, and >>refrain >>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will >>try out >>all these different 2.2 branches, so these fixes won't get additional >>testing. In the contrary, I believe that they would get more testing >if >>they >>were all in one 2.3 branch. Also, I doubt that we can now plan ahead >>for >>2.2.2, these plans are likely to become obsolete. We have a simple >tool >>to >>schedule bug fixes: Milestones in trac. If we put all bug fixes in the >>2.3 >>branch and set the bug milestones it is easy to get a list of all >fixes >>that >>need backporting. >> >> >>Georg > >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