You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/11/07 22:07:26 UTC
Final counting approaches...
Ok, after long debate on list, resistance from some quarters, and much
support from others, we need to draw this to a conclusion.
Since I brought it up, I'm willing to do the work. Depending on the
collective will of the project, I'm prepared to do the following on
Monday;
. check out APACHE_2_0_43, then move to the current version
on all files that don't change the API or module structure.
. tag those files 2_0_44_PRE1
. allow a week for testing, comments, new patches, reverting wrong
patches, votes etc.
Then in the afternoon of Monday the 18th, based on the final voting
in STATUS;
. RM the 2.0.44 candidate based on the final _PREn tag we worked out.
. Create an APACHE_2_0_BRANCH for all future patches into 2.0.
. Bump ap_revision to 2.1.0-dev for cvs HEAD.
. Create a document for committers, both code and docco folks, that
describes the CTRTC process (commit to head, then review, then
commit to 2.0-stable) and how to use CVS for this purpose.
So -please- express your final opinions to the list, and your votes to
the STATUS file.
Bill
>From httpd-2.0/STATUS;
CURRENT VOTES:
* Adopt backwards compatibility for future Apache 2.0 releases
such that MMN major number changes and eliminating non-experimental
modules are deferred for the next minor version bump (e.g. 2.1, 2.2
or 3.0).
+1: wrowe, jerenkrantz, aaron, brianp, trawick, stoddard, jwoolley,
rbowen, rederpj
0:
-1:
* Defer the Auth module overhaul to the next minor version bump
(e.g. 2.1, 2.2, 3.0) on the condition that forward compatibility
resolution is adopted.
+1: wrowe, aaron, trawick, stoddard, jwoolley, rbowen, gregames,
rederpj
0: jerenkrantz
-1:
* Adopt an even/odd release paradigm (see VERSIONING) such that
even numbered releases are stable, and odd numbered releases
are development efforts, keeping in the tradition of Linux,
Perl, etc. In pratical terms, this implies C-T-R-T-C, where
patches are (generally) first applied to the development branch,
tested, and then (after vote) applied to the stable branch.
+1: wrowe, jerenkrantz, aaron, trawick, stoddard, jwoolley, rbowen,
gregames, rederpj
0:
-1:
* Branch APACHE_2_0_BRANCH today, changing the version in CVS HEAD
to 2.1.0-dev.
+1 [from APACHE_2_0_43*]: wrowe, aaron, trawick, stoddard, jwoolley,
gregames, rederpj
+1 [from HEAD]:
0: jerenkrantz
-1:
* Note, The reason I'm suggesting the 2.0 branch from the 2.0.44 point
is that folks have applied many fixes to 2.0, and shouldn't go back and
reconsider all of that work. If a wrong patch is grabbed at that branch point
(that we don't discover immediately) then we can revisit it in a 2.0.45 release.
Without that two-branch approach in place already, it's unreasonable for folks
to go back over a month or two of bug fixing efforts.
RE: Final counting approaches...
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:49 AM 11/8/2002, Sander wrote:
>I wouldn't mind taking on the RM job for 2.0.44.
And I won't mind giving it away :-)
However, prepare to lay down the tag Monday and start working
with both the dev and docs lists to gather as much of the docs work
into 2.0.44 as we can (under a 2_0_44_PRE1 tag). Only auth and
auth-related changes (and other MMN-major changes) are avoided.
The big trick is that we squeeze as much of this 'goodstuff'(TM) into
that tag so that when we branch 2.1, there is very little merging of
old work left to do. Only committers after that fork need to worry
about merging their changes from HEAD back to APACHE_2_0_BRANCH
and even at that, those merges should apply cleanly.
The only thing to begin tracking are bits committed next week that
are not picked up with the APACHE_2_0_44 tag that are appropriate
now, or soon, for the APACHE_2_0_BRANCH (based on R-T-C!)
Expect another release or two from the APACHE_2_0_BRANCH before
the 2.1-dev branch is ready-to-roll into a 2.2-GA release in about 3 mos,
and probably maintenance/security releases on 2.0 even after 2.2 is
widely available.
Bill
RE: Final counting approaches...
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:49 AM 11/8/2002, Sander wrote:
>I wouldn't mind taking on the RM job for 2.0.44.
And I won't mind giving it away :-)
However, prepare to lay down the tag Monday and start working
with both the dev and docs lists to gather as much of the docs work
into 2.0.44 as we can (under a 2_0_44_PRE1 tag). Only auth and
auth-related changes (and other MMN-major changes) are avoided.
The big trick is that we squeeze as much of this 'goodstuff'(TM) into
that tag so that when we branch 2.1, there is very little merging of
old work left to do. Only committers after that fork need to worry
about merging their changes from HEAD back to APACHE_2_0_BRANCH
and even at that, those merges should apply cleanly.
The only thing to begin tracking are bits committed next week that
are not picked up with the APACHE_2_0_44 tag that are appropriate
now, or soon, for the APACHE_2_0_BRANCH (based on R-T-C!)
Expect another release or two from the APACHE_2_0_BRANCH before
the 2.1-dev branch is ready-to-roll into a 2.2-GA release in about 3 mos,
and probably maintenance/security releases on 2.0 even after 2.2 is
widely available.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
RE: Final counting approaches...
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu74-177-063.nc.rr.com
> [mailto:trawick@rdu74-177-063.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 08 November 2002 14:41
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
>> Ok, after long debate on list, resistance from some quarters, and much
>> support from others, we need to draw this to a conclusion.
>>
>> Since I brought it up, I'm willing to do the work. Depending on the
>> collective will of the project, I'm prepared to do the following on
>> Monday;
>
> +1
I wouldn't mind taking on the RM job for 2.0.44.
Sander
Re: Final counting approaches...
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Ok, after long debate on list, resistance from some quarters, and much
> support from others, we need to draw this to a conclusion.
>
> Since I brought it up, I'm willing to do the work. Depending on the
> collective will of the project, I'm prepared to do the following on
> Monday;
+1
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: Final counting approaches...
Posted by Bill Stoddard <bi...@wstoddard.com>.
> And the final option once APR is at 1.0 is to release an APR 1.0 release
> of Apache 2.0.x. We would break our own versioning rules for the 2.0.x
> series, but folks haven't come to expect much stability out of 2.0 in the
> first place.
I think re-releasing 2.0.x against APR 1.0 would be a mistake (I am assumiming
of course that APR 1.0 would not be compatable with APR 0.9.x). We are about to
send a signal to our users that 2.0.x is now 'stable'. If we break it, that
just flushes our efforts down the tubes, don't you think? Our message to the
user community should be easy to understand, direct and should not contain more
than ONE caveat. I think our message should state that every release in the 2.0
series from 2.0.42 on out WILL be binary compatable with the previous releases.
The only caveat is if we discover a serious security exposure that requires
breaking binary compatability. Introducing an APR 1.0 caveat would not be cool
IMHO.
Bill
Re: Final counting approaches...
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
[Context: we are discussing the creation of an APACHE_2_0_RELEASE
branch and forking off API-breaking changes to a 2.1-dev branch. Greg's
question goes to APR, which is why it's cc'ed. Please keep this cross
posted thread about how Apache and APR versioning interact on topic :-]
At 11:01 AM 11/8/2002, Greg Ames wrote:
> What about apr? the same?
No.
APR isn't Apache, nor should it be.
I see the following happening to APR;
* Tag APACHE_2_0_44 just as we've done for every release *thus far*.
* Fork APACHE_2_0_BRANCH only within the httpd-2.0.
Now; once the APR project reaches 1.0, we can consider releasing 2.2.
APR will be following it's own well-defined versioning contract with
developers. Any Apache 2.2+ will build under any APR 1.x until *we*
decide to break binary compatibility with APR 1.n-1 or prior (when we
choose to use some new API introduced in 1.n.) If that breaks our
long-term compatibility goals, we can always kick off 2.4, requiring
the given APR 1.n. This probably won't be required since the Apache
project hasn't put forward any forward compatibility guidelines.
Our APACHE_2_0_BRANCH may always use an APR 0.9.x. If a security
patch requires an update to that 'final release' of APR 0.9.x, we can all
decide what to do about it then (perhaps create a maintenance fork from
APR 0.9.x.)
And the final option once APR is at 1.0 is to release an APR 1.0 release
of Apache 2.0.x. We would break our own versioning rules for the 2.0.x
series, but folks haven't come to expect much stability out of 2.0 in the
first place.
If the APR project didn't believe it was close-ish to the 1.0 release, the
entire Apache versioning proposal wouldn't even be on the table :-)
Bill
Re: Final counting approaches...
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
[Context: we are discussing the creation of an APACHE_2_0_RELEASE
branch and forking off API-breaking changes to a 2.1-dev branch. Greg's
question goes to APR, which is why it's cc'ed. Please keep this cross
posted thread about how Apache and APR versioning interact on topic :-]
At 11:01 AM 11/8/2002, Greg Ames wrote:
> What about apr? the same?
No.
APR isn't Apache, nor should it be.
I see the following happening to APR;
* Tag APACHE_2_0_44 just as we've done for every release *thus far*.
* Fork APACHE_2_0_BRANCH only within the httpd-2.0.
Now; once the APR project reaches 1.0, we can consider releasing 2.2.
APR will be following it's own well-defined versioning contract with
developers. Any Apache 2.2+ will build under any APR 1.x until *we*
decide to break binary compatibility with APR 1.n-1 or prior (when we
choose to use some new API introduced in 1.n.) If that breaks our
long-term compatibility goals, we can always kick off 2.4, requiring
the given APR 1.n. This probably won't be required since the Apache
project hasn't put forward any forward compatibility guidelines.
Our APACHE_2_0_BRANCH may always use an APR 0.9.x. If a security
patch requires an update to that 'final release' of APR 0.9.x, we can all
decide what to do about it then (perhaps create a maintenance fork from
APR 0.9.x.)
And the final option once APR is at 1.0 is to release an APR 1.0 release
of Apache 2.0.x. We would break our own versioning rules for the 2.0.x
series, but folks haven't come to expect much stability out of 2.0 in the
first place.
If the APR project didn't believe it was close-ish to the 1.0 release, the
entire Apache versioning proposal wouldn't even be on the table :-)
Bill
Re: Final counting approaches...
Posted by Greg Ames <gr...@apache.org>.
William A. Rowe, Jr. wrote:
> Ok, after long debate on list, resistance from some quarters, and much
> support from others, we need to draw this to a conclusion.
>
> Since I brought it up, I'm willing to do the work. Depending on the
> collective will of the project, I'm prepared to do the following on
> Monday;
Excellent...thanks much!
> . check out APACHE_2_0_43, then move to the current version
> on all files that don't change the API or module structure.
>
> . tag those files 2_0_44_PRE1
>
> . allow a week for testing, comments, new patches, reverting wrong
> patches, votes etc.
+1
What about apr? the same?
Greg