-Paul
Justin Erenkrantz wrote:
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
