httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject [PROPOSAL] How to treat release candidate branches
Date Wed, 23 Feb 2005 16:03:48 GMT
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