httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Final counting approaches...
Date Thu, 07 Nov 2002 21:07:26 GMT
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

. 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

. 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.


>From httpd-2.0/STATUS;


    * 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

    * 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,
         0: jerenkrantz

    * 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

    * 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

* 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.

View raw message