Hi, On 10/12/2010 10:43 AM, Kris Popat wrote: > > On 11 Oct 2010, at 21:22, Scott Wilson wrote: > >> >> On 11 Oct 2010, at 18:06, Luciano Resende wrote: >> >>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <[email protected]> >>> wrote: >>>> On 11/10/2010 04:06, Scott Wilson wrote: >>>>> >>>>> (Maybe we need another discussion around branching strategy - e.g. do >>>>> we have different branches for release versions (e.g. a 0.9.0 branch >>>>> and a 0.9.1. branch), or do we keep on having the current code in >>>>> trunk and just do potentially-disruptive feature development in >>>>> branches?) >>>> >>>> There are many ways of doing this. The way I personally prefer (but >>>> never >>>> insist upon, others should suggest alternatives) is: >>>> >>>> - at code freeze for a release create a branch in which the release >>>> will be >>>> built (this allows development to continue in trunk even while >>>> release build >>>> and testing is underway) >>>> >>>> - once the release is approved and built tag trunk as 0.9.0 or >>>> whatever My question will probably sounds stupid, but I would like to understand. Why do we make a tag from trunk and not from the branch ? Besides, where will be committed changes between branch creation and tag build : trunk, branch, branch then trunk or trunk then branch ? I mean there are several cases : bug fix in trunk, bug fix in branch and probably some other ones ? >>>> >>>> - use the branch for maintenance of the release (i.e. security >>>> fixes that >>>> can't wait for the next release from trunk) >>>> >>> >>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2, >>> etc). I'd just mention that, for the maintenance release it's probably >>> enough to just have a tag created and continue to use the same branch >>> (e.g 0.9.0) >> >> +1 also. I was thinking about how we might start work on the oAuth >> integration and other new features while still being able to make >> maintenance releases of 0.9.0 if there are critical bugs found. I >> think that answers it nicely. >> > > +1 yes, I was thinking this myself, the only issue that we might need > to be aware of is if testing of the release package comes up with some > issues that need to be fixed then we also need to remember to merge > those fixes back into truck. > > >>>> Creating branches for disruptive features is important to allow >>>> people to >>>> continue to develop in trunk. However, they should only be created >>>> when >>>> really necessary as it can be difficult to maintain a branch. >>>> >>> >>> +1, and they should be merged back as soon as they are stable and >>> people agree with it. >> >> +1 It was good to work with Randy on the JPA/JCR stuff in a branch >> for this purpose, but it was a lot of overhead to keep it in sync >> with trunk, so I'd definitely prefer to only do this for major >> replumbing. >> > > +1 +1 I got this one, no need for explanation ;-) >>>> Whatever policy is adopted needs to be documented in the relase >>>> management >>>> documents I hope Kris will put together as he works through this >>>> process. >>>> >>> >>> +1 >> +1 > > +1 Yes am working on some initial release management documents at the > moment on the wiki, will post later when they are up +1 Thank you for documenting all of that.
Thomas.
