Fwd: Final counting approaches...

["William A. Rowe, Jr." <wr...@apache.org>]

Sorry, this should have been copied to the docs list as well from the
get-go.  The general idea of beginning the apache 2.0/2.1 split is to
FIRST minimize any initial fixup, other than assure that the new auth
docs remain in cvs HEAD (becoming 2.1) while we pick up 'just the
right version' for auth docs at the branch point.

Without this message, my reply to Sander next one makes no sense...

Bill

>Date: Thu, 07 Nov 2002 15:07:26 -0600
>To: dev@httpd.apache.org
>From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
>
>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.


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org