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 >> >> - 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. >> 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. >> 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 > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
smime.p7s
Description: S/MIME cryptographic signature
