httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PROPOSAL] How to treat release candidate branches
Date Wed, 23 Feb 2005 16:11:53 GMT
+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

Mime
View raw message