On 12/10/2010 01:43, 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
- 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.
Yes, that's the "downside" of branching rather than doing a code freeze.
In a small community like this a code freeze for a short period is
usually not a major problem. However, as the community grows the
overhead of managing the branch and trunk is worthwhile and has to be
done anyway for emergency maintenance releases of the branch.
Ross
