httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [PROPOSAL] Branch 2.1.x on May 13
Date Mon, 02 May 2005 20:37:06 GMT
At 05:45 PM 4/29/2005, Paul Querna wrote:

>I think that most other developers agree that 2.1.x/trunk has enough
>features for a 2.2.x GA branch.


>I believe 2.1.x is a moving target.

+/- 0.  I see the tree is fairly stable, has some decent bug fixing
activity, and nothing destabling.  To the extent that 'I want this
feature in version x.y' that always happens, and can be ignored unless
there is code to consider.

>I think it is hard to stabilize a moving target.

+1 if it was moving.  -1 to your statement.

>I believe we should always keep trunk open for development.


>I believe in order to create a stable 2.1.x, in preparation for a 2.2.x
>GA branch.

We discussed this at ApacheCon.  When we have something betaworthy,
the candidate should be simply svn cp'ed to a branch.

>I think we should branch 2.1.x from trunk to stabilize it.

-1 - I don't see trunk as unstable.

>Once 2.1.x is in a branch, I believe trunk should become 2.3.x.

-1 - but close.  Once 2.2 is branched, then 2.1 is dead.  Trunk
does immediately become 2.3.x at that point, yes.

>I believe having 2.1.x in a stabilization branch will speed the release
>of 2.2.x.


>I believe that 2.1.x should have a set branch date.  Based on past
>history, I do not think we have been successful without a set date.
>I am proposing the branch date be May 13, 2005.

The 'problems' aren't with the branch date, although an alpha tag
(with the intent to become beta) as of that date would always be

The problem is really that there will be alot of float between first
beta and final.  I'm suggesting the goal isn't date setting the branch,
it's date setting the final release after branch.

I'm not convinced branching before beta buys us anything, but sure
am convinced that we have to branch when we go beta.

The nice bit is that rather than copying from trunk, once we have some
2.1.6-alpha we want to decree as 2.2.0-beta, we copy from the 2.1.6
tag.  So trunk really isn't in our way.

 From discussion - I see us branching 2.1.x anyways, but still object 
since we will now be maintaining two or three backports for every 
bugfix commit to trunk/.  Humbly suggest this isn't the conclusion 
we reached at AC Las Vegas, and suggest it's still the wrong solution 
to a non-problem.

In short IMHO - get alpha to beta; set a short date for GA (keep pain
minimal); spin 1x - 3x on beta till release, get 2.2 out the door.
A one month window of parallel 2.3 Trunk/2.2 Branch/2.0 Branch backports
are a pain, but if we can keep the window short we shouldn't suffer to


View raw message