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
- 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
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
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
