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
