> I don't think what we currently do is really the best. I > think your notion of having a branch where work is done for > the impending release probably makes more sense. Leaving HEAD > for the most current development processes target for > subsequent releases also makes more sense to me as well.
I agree. We could do this now by declaring the RC2 branch as the 1.0 branch, and making HEAD 1.1. (when it comes down to details, I'd prefer to actually recreate the branch so it's a cleaner merge as it currently contains parts of HEAD up to the last merge tag point, but we can discuss this later). > But I agree with Dion that you cannot start making changes or > additions to HEAD which is currently slated for 1.0 until we > figure out what we're going to do wrt what branches will be > for what versions and what HEAD actually represents to us. The main problem with using HEAD for "unstable" development is that people start to complain when it doesn't work properly. I think we'll get over that as we have separated the plugins and move towards better tested, component oriented development as it is less likely to have the same severe impact as ripping apart the most central class has had this time around :) > > Vincent, I'm all for what you suggest as it means we can > actually develop easier in parallel but some simple naming > schemes and a small paragraph describing how we move from > branch to branch would be nice. > I agree. For a short description, you can read the section "the flying fish approach" in the CVS Open Source Development book: http://cvsbook.red-bean.com/cvsbook.html#The_Flying_Fish_Approach_--_A_Simpl er_Way_To_Do_It (warning - this is a 600K HTML document for those on a modem - here is the links to other downloads http://cvsbook.red-bean.com/ :) The whole chapter on branches is quite good. Cheers, Brett
