On Friday 10 August 2007 08:45:43 pondlife wrote: > > 4-6. Everyone is encouraged to fix bugs in the rel-3.0 branch. > > Maybe this should be in the trunk - i.e. bug fix week or freeze. That > saves us having to fix said bugs in both trunk and 3.0.
IMO this is exactly what using branches is meant to avoid. Declaring a feature freeze on the trunk is one of the reasons the last attempt at a 3.0 release failed. Most devs simply weren't interested in doing *only* bugfixing work. Using a branch to avoid feature freeze gives a choice between adding new features in the trunk (which shouldn't be encouraged) and fixing bugs in both the release branch and the trunk. Of course you could say that fixing in both branches is a duplication of effort, but at this point it should be quite trivial to do, as the branches shouldn't be too far apart. > > 7. ...After this (or possibly during 4-6), new features should get into > > trunk... > > If you do 4-6 as per your plan, then new features must be allowed into > trunk immediately (i.e. no freeze). > If you do 4-6 as I suggest above, then we only allow new features at 7. As I said above, adding new features to trunk between branching and release shouldn't be forbidden, but simply not encouraged. What is most likely to happen anyway is that people will try to get their new features in before the branching because they'll want them to be in the release. Then it's expected that they should at least help debug their features. If we were to freeze the trunk past a certain date instead of branching, someone who had a new feature to add but missed the freeze date would be frustrated both of having missed the release deadline and of having to maintain a patch he can't commit because of the freeze. Nicolas
