+1
>>> justin@erenkrantz.com Wednesday, February 23, 2005 9:03:48 AM >>>
Assuming that we can get a beta approved to eventually become 2.2.x,
I'd like
to propose the following policy that tries to balance the need for
review with
the need for stability:
Any code changes can be backported to a release candidate branch from
trunk
via lazy consensus (CTR) if it does not change binary compatibility.
However,
if a change impacts binary compatibility or the external API in anyway
(i.e.
adds a new function or whatnot), it must receive 3 +1s before it can be
committed to the release candidate branch (RTC).
This way, we can add new features or binary-incompatible changes to a
beta if
three committers are in agreement that it should be present before the
stable
release. And, bug fixes ported back from trunk can be brought back
with
minimal hassle.
At the point that we issue the first GA release, everything in that
release
candidate branch switches over to RTC (as we do right now for 2.0.x).
Of
course, this would not apply to trunk - which remains under CTR for all
changes.
For those who like concrete examples: If 2.1.3 is approved, we copy the
tags/2.1.3 to branches/2.2.x. Trunk becomes 2.3.0. branches/2.2.x is
immediately bumped to 2.1.4 (or perhaps 2.1.5 to identify those
snapshots that
came from the trunk before we branched). All changes must still hit
the trunk
(2.3.0) first. If you have a bug fix or a change that doesn't impact
the API,
it can be immediately backported to branches/2.2.x under CTR. If it
changes
the API in any way, it must enter branches/2.2.x/STATUS to receive
votes for
backport.
What do ya'll think? -- justin
|