httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r554685 - /httpd/site/trunk/xdocs/dev/release.xml
Date Mon, 09 Jul 2007 16:47:54 GMT
Before I SVN up to the site, some quick eyeballs on my changes r554684 and
this commit?  It's been very confusing as I refer incubating people back
to this document, while pounding the +3 votes before a release ASF-wide
policy.


wrowe@apache.org wrote:
> Author: wrowe
> Date: Mon Jul  9 08:37:38 2007
> New Revision: 554685
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=554685
> Log:
> Revert 2.0.x generation changes that were invalid.  All releases
> require a vote and approval by the project members.
> 
> (Anything without three +1's is nothing but a snapshot by another name.)
> 
> Modified:
>     httpd/site/trunk/xdocs/dev/release.xml
> 
> Modified: httpd/site/trunk/xdocs/dev/release.xml
> URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/dev/release.xml?view=diff&rev=554685&r1=554684&r2=554685
> ==============================================================================
> --- httpd/site/trunk/xdocs/dev/release.xml (original)
> +++ httpd/site/trunk/xdocs/dev/release.xml Mon Jul  9 08:37:38 2007
> @@ -11,10 +11,18 @@
>  Apache HTTP Server Project to create releases of httpd-2.0 (the current
>  Apache 2.0 branch).  As described herein, this policy is not set in stone
>  and may be adjusted by the Release Manager.</p>
> +
> +<p>With the introduction of Apache 2.1, the Apache httpd project has
> +adopted an odd-even release strategy, where development happens with
> +alpha and beta releases assigned an odd-numbered minor version, and its
> +general availability (stable) release is designed with the subsequent
> +even-numbered minor version.  E.g. 2.1.0-alpha through 2.1.6-alpha
> +were followed by 2.1.7-beta through 2.1.9 beta, and cumulated in the
> +2.2.0 general availability release.<p>
>  </section>
>  
>  <section><title>Who can make a release?</title>
> -<p>Technically, any one can make a release of the source code due to the
> +<p>Technically, anyone can make a release of the source code due to the
>  <a href="http://www.apache.org/licenses/">Apache Software License</a>.
>  However, only members of the Apache HTTP Server Project (committers)
>  can make a release designated with Apache.  Other people must
> @@ -31,13 +39,12 @@
>  <section><title>Who is in charge of a release?</title>
>  <p>The release is coordinated by the Release Manager (hereafter, abbreviated
>  as RM).  Since this job requires coordination of the development community
> -(and access to CVS), only committers to the project can be RM.  However,
> +(and access to subversion), only committers to the project can be RM.  However,
>  there is no set RM.  Any committer may perform a release at any time.  In
>  order to facilitate communication, it is deemed nice to alert the
>  community with your planned release schedule before executing the
>  release.  A release should only be made when there is a plan to publicly
> -release it.  (A release should not be made only for private distribution.
> -A private release is more suitable for that.)</p>
> +release it.  (A release must not be made only for private distribution).</p>
>  </section>
>  
>  <section><title>Who may make a good candidate for an RM?</title>
> @@ -59,7 +66,7 @@
>  entry is resolved.  These items may be bugs, outstanding vetos that have
>  not yet been resolved, or enhancements that must make it into the
>  release.  Note that the RM may also add showstopper entries to indicate
> -what issues must be resolved before a release may be created.</p>
> +what issues must be resolved before they intend to create a release.</p>
>  </section>
>  
>  <section><title>What power does the RM yield?</title>
> @@ -91,7 +98,8 @@
>  <p>The RM may perform sanity checks on release candidates.  One highly
>  recommended suggestion is to run the httpd-test suite against the candidate.
>  The release candidate should pass all of the relevant tests before making
> -it official.</p>
> +it official, and certainly avoid new regressions (tests that previously
> +passed, and now fail).</p>
>  
>  <p>Another good idea is to coordinate running a candidate on apache.org for
>  a period of time.  This will require coordination with the current
> 
> 
> 
> 


Mime
View raw message