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
