2008/6/23 Kalle Kärkkäinen <[EMAIL PROTECTED]>: > Hi, > > Aidan Skinner: >> >> hack awesome shiny bugfix feature >> trunk >> ----*-------*-------^-------*-------^---------*---------*-----------> >> | | | >> M3.x---*---------------*-------------------------------> >> fix | critfix | >> M3.0 M3.0 >> RC1 FINAL > > I'm entering a conversation I've only lurked over, but here goes.. > > As surely everyone on the list has experienced before, this is a common > battle between branches and 'the-way-forward'. A balancing act between > maintenance and new features or even more so balancing a process so that it > still allows development and does not stagnate to bug fixes. > > I'm sure you people have tackled this successully before so I'll be brief. > > We have the trunk that continuously goes forward, and from that we freeze > branches that receive only bugfixes. This would mean that any given release > (or release candidate) with designated feature set can be honed to > perfection and the relevant fixes may be applied to the trunk. > > But it also allows the trunk to be moving forward with greater speed and > (possibly) more demanding refactoring work. Of course, in this thinking, > branches are a one way street, bidirectionality is unwanted as in my > experience it leads into situations where it's really hard to say what > patches have been applied to what branches. > > -- > Kalle. >
I'm not sure if the bi-directional merging is really what we would do. As Kalle says if trunk undergoes major refactoring (as has just occur ed in the java broker) then merging changes from trunk to any MX.x branch isn't going to be possible. Hence a new M(X+1).x branch would be required for releasing those changes. I would say that if a new trunk feature was required/desired on an existing MX.x branch then that feature would need to be 'ported' rather than merged. I would say the same is true for bug fixes, if a bug fix on trunk is done then if the test also highlights the problem exists on a MX.x branch then the patch may not merge over due to refactoring etc. but the JIRA system should be able to record the bug and the fixed locations. Sure it means that a svn log is not going to tell you what code has been ported but ideally commit logs would have sensible text along with JIRA IDs which would allow the correlation. I think the revised approach with tagging at release point will work otherwise we may end up with a lot of branches needing love. Having a single MX.x branch per major release means that we are not thinking that we will provide patches on all previous releases only the major MX releases. I don't think our users would need or even want to have patching to the level of MX.Y(with Patch a) up to MX.(Y+n) (with Patch a). We then get in to issues of what we call that. MX.Y.Z? That would work if we always apply all patches to all branches but if we skip one for some reason then I'd say it all gets pretty muddy pretty quickly. Hope that makes some sense.. my brain may not have spun up to speed after a relaxing week off. Cheers Martin -- Martin Ritchie
