httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: httpd-site/xdocs/dev release.xml
Date Tue, 28 May 2002 17:06:09 GMT
jerenkrantz    02/05/28 10:06:09

  Added:       docs/dev release.html
               xdocs/dev release.xml
  Log:
  Add a document that describes our release policies and release guidelines.
  
  This is not a walkthrough of a release (see how-to-release for that), but
  attempts to explain what the high-level overview of our release process is.
  This also explains the alpha, beta, GA designations which has been woefully
  undocumented anywhere.
  
  Feel free to correct any mistakes.
  
  Revision  Changes    Path
  1.1                  httpd-site/docs/dev/release.html
  
  Index: release.html
  ===================================================================
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html>
   <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
         <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org"
/>
      <title>Apache HTTP Server Release Guidelines - The Apache HTTP Server Project</title>
   </head>
   <body bgcolor="#ffffff" text="#000000" link="#525D76">
  <p><a href="/"><img src="../images/httpd_logo_wide.gif" alt="The Apache HTTP
Server Project" border="0"/></a></p>
   <table border="0" width="100%" cellspacing="4">
     <tr>
      <!-- LEFT SIDE NAVIGATION -->
      <td valign="top" nowrap="nowrap">
             <p><b>Essentials</b></p>
      <menu compact="compact">
            <li><a href="/ABOUT_APACHE.html">About</a></li>
            <li><a href="http://www.apache.org/LICENSE.txt">License</a></li>
            <li><a href="/docs/misc/FAQ.html">FAQ</a></li>
            <li><a href="/security_report.html">Security<br />Reports</a></li>
          </menu>
        <p><b>Download!</b></p>
      <menu compact="compact">
            <li><a href="http://www.apache.org/dyn/closer.cgi/httpd/">from a mirror</a></li>
            <li><a href="http://www.apache.org/dist/httpd/">from here</a></li>
          </menu>
        <p><b><a 
  href="/docs-project/">Documentation</a></b></p>
      <menu compact="compact">
            <li><a href="/docs/">Apache 1.3</a></li>
            <li><a href="/docs-2.0/">Apache 2.0</a></li>
          </menu>
        <p><b>Get Involved</b></p>
      <menu compact="compact">
            <li><a href="/lists.html">Mailing Lists</a></li>
            <li><a href="/bug_report.html">Bug Reports</a></li>
            <li><a href="/dev/">Developer Info</a></li>
          </menu>
        <p><b>Subprojects</b></p>
      <menu compact="compact">
            <li><a href="/docs-project/">Docs</a></li>
            <li><a href="/test/">Test</a></li>
          </menu>
        <p><b><a 
  href="/info/">Miscellaneous</a></b></p>
      <menu compact="compact">
            <li><a href="/contributors/">Contributors</a></li>
            <li><a href="/awards.html">Awards</a></li>
            <li><a href="http://nav.webring.org/navcgi?ring=apachesupport;list">Support<br
/>Webring</a></li>
          </menu>
      </td>
      <!-- RIGHT SIDE INFORMATION -->
      <td align="left" valign="top">
                  <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Introduction</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>This document describes the general release policies used by the
  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>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Who can make a release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Technically, any one can make a release of the source code due to the
  <a href="http://www.apache.org/LICENSE.txt">Apache Software License</a>.
  However, only members of the Apache HTTP Server Project (committers) to
  project can make a release designated with Apache.  Other people must
  call their release something other than "Apache" unless they obtain
  written permission from the Apache Software Foundation.</p>
  <p>Following our official release policies, we will only accept release
  binaries from members of the Apache HTTP Server Project for inclusion on our
  website.  This ensures that our binaries can be supported by members of
  the project.  Other people are free to make binaries, but we will not
  post them on our website.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Who is in charge of a release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <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,
  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>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Who may make a good candidate for RM?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Someone with lots of time to kill.  Being an RM is a very important job
  in our community because it takes a fair amount of time to produce a stable
  release.  If you feel lucky, a release could be distributed without testing,
  but our experience has shown that leads to a higher number of <i>dud</i>
  releases.  In general, our experience has shown that a well-coordinated
  release fares better than non-coordinated releases.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>When do I know if it is a good time to release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>It is our convention to indicate <i>showstoppers</i> in the STATUS
  file in the repository.  A showstopper entry does not automatically
  imply that a release can not be made.  As the RM has final authority
  on what makes it into a release, they can choose to ignore the entries.
  An item being denoted as a <i>showstopper</i> indicates that the group
  has come to a consensus that no further releases can be made until the
  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>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>What power does the RM yield?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Regarding what makes it into a release, the RM is the unquestioned
  authority.  No one can contest what makes it into the release.  The
  community will judge the release's quality after it has been issued,
  but the community can not force the RM to include a feature that they
  feel uncomfortable adding.  Remember that this document is only a
  guideline to the community and future RMs - each RM may run a release
  in a different way.  If you don't like what an RM is doing, start
  preparing for your own competing release.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>How does an impending release affect development?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>It can not.  Let's repeat that: <b>an impending release can not affect
  development of the project</b>.  It is the RM's responsibility to identify
  what changes should make it into the release.  The RM may have an
  intermediate tag, so the RM can merge in or reject changes as they are
  committed to the repository's HEAD.</p>
  <p>Committers <i>may</i> voluntarily refrain from committing patches if
  they wish to ease the burden on the RM, but they are under
  <font color="red">no</font> obligation to do so.  This is one reason why we
  recommend that the RM have plenty of time on their hands - they may have to
  deal with a rapidly changing target.  It's not an easy job.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>How can an RM be confident in a release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <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>
  <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
  maintainers of apache.org's httpd instance.  In the past, the group has
  liked to see approximately 48-72 hours of usage in production to certify
  that the release is functional in the real world.  Note that some committers
  may choose to not vote on a release until feedback has been gathered from the
  apache.org instance running the release.  This is not a requirement (each
  committer is free to come up with their own personal voting guidelines),
  but it produces a feeling of confidence in the release that it will not
  be a <i>dud</i>.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>How to do a release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Once the tree has been suitably tested by the RM and any other
  interested parties, they should "roll" the release.</p>
  <p>Key points:</p>
  <ul>
  <li>Ensure that the RM's PGP/GPG key is in the httpd-dist/KEYS file</li>
  <li>Create an official APACHE_X_Y_Z tag based of the candidate tree</li>
  <li>Run httpd_roll_release script</li>
  <li>Copy the generated release tarballs and signatures to
  daedalus:/www/httpd.apache.org/dev/dist</li>
  <li>Email dev@httpd.apache.org, current-testers@httpd.apache.org, stable-testers@httpd.apache.org
to inform them of the release.</li>
  </ul>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>What can I call this release?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>At this point, the release is an alpha.  The Apache HTTP Server Project
  has three classifications for its releases:</p>
  <ul>
  <li>Alpha</li>
  <li>Beta</li>
  <li>General Availability (GA)</li>
  </ul>
  <p>Alpha indicates that the release is not meant for mainstream usage or
  may have serious problems that prohibits its use.  When a release is
  initially created, it automatically becomes alpha quality.</p>
  <p>Beta indicates that at least three committers have voted positively
  for beta status and there were more positive than negative votes for
  beta designation.  This indicates that it is expected to compile and
  perform basic tasks.  However, there may be problems with this release
  that prohibit its widespread adoption.</p>
  <p>General Availability (GA) indicates that at least three committers
  have voted positively for GA status and that there were more positive
  than negative votes for GA designation.  This release is recommended
  for production usage.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Who can vote?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Non-committers may cast a vote for a release's quality.  In fact,
  this is extremely encouraged as it provides much-needed feedback to
  the community about the release's quality.  However, only binding
  votes casted by committers count towards the designation.</p>
  <p>Note that no one may veto a release.  Releases may not receive a
  designation level if a problem is found that inhibits proper
  functionality.  The group may (implicitly or explicitly) revoke all votes
  on a release if there is a problem.  However, if there is a -1 vote for
  a particular designation and there are greater than 3 positive votes
  and more positive than negative votes (i.e. majority consensus), the
  appropriate designation is conferred upon the release.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>How do we make it public?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>Once the release has reached the highest-available designation (as deemed
  by the RM), the release can be moved to the httpd distribution directory
  on apache.org.  Approximately 24 to 48 hours after the files have been moved,
  a public announcement can be made.  We wait this period so that the mirrors
  can receive the new release before the announcement.  An email can then be
  sent to the announcements lists (announce@apache.org,
  announce@httpd.apache.org).  Drafts of the announcement are usually
  posted on the development list before sending the announcement to let the
  community clarify any issues that we feel should be addressed in the
  announcement.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Should the announcement wait for binaries?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>In short, no.  The only files that are required for a public release
  are the source tarballs (.tar.Z, .tar.gz).  Volunteers can provide
  the Win32 source distribution and binaries, and other esoteric
  binaries.</p>
  <p>Note that the typical Win32 source distribution differs from the
  original tarball in that it has generated project files as well as
  the CRLF line endings required for that platform.  More information
  can be found <a href="http://httpd.apache.org/docs-2.0/platform/win_compiling.html">here</a>.
  </p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Oops.  We found a problem.</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>At this point, the release has been created.  No code changes can be
  made in this release.  If a problem is found, it will have to be addressed
  in the next release or a patch can be made available.  No changes can
  be made between alpha, beta, and GA status.  The only difference is the
  file name that is downloaded by the users.  If an alpha tarball is created,
  but there was an error that can be resolved by re-rolling the tarball,
  it may be permissible to re-roll the release.  But, the code itself may
  <font color="red">not</font> change from designation to designation.</p>
  <p>There are two courses of action:</p>
  <p>Revoke the release and immediately create another one that has a fix
  to this problem.  You can take the old release, apply the single patch,
  and start the voting process again.  This is only recommended for
  critical problems found early on in the release cycle.</p>
  <p>If the problem is less severe, place the patch to the problem in the
  /dist/httpd/patches/apply_to_X.Y.Z directory.  A link to this directory
  should be included in the release notes with descriptions as to what
  problem each patch addresses.</p>
    </blockquote>
   </td></tr>
  </table>
             <table border="0" cellspacing="0" cellpadding="2" width="100%">
   <tr><td bgcolor="#525D76">
    <font color="#ffffff" face="arial,helvetica,sanserif">
     <strong>Suggestions?</strong>
    </font>
   </td></tr>
   <tr><td>
    <blockquote>
  <p>As always, if you have any suggestions or comments on our process,
  please feel free to email our developer mailing list with your comments.
  We hope you found this document useful.</p>
    </blockquote>
   </td></tr>
  </table>
           </td>
     </tr>
     <!-- FOOTER -->
     <tr><td colspan="2"><hr noshade="noshade" size="1"/></td></tr>
     <tr><td colspan="2" align="center">
          <font size="-1">
           <em>Copyright &#169; 1999-2002, The Apache Software Foundation</em>
          </font>
         </td>
     </tr>
    </table>
   </body>
  </html>
  
  
  
  1.1                  httpd-site/xdocs/dev/release.xml
  
  Index: release.xml
  ===================================================================
  <?xml version="1.0"?>
  <document>
    <properties>
      <author email="docs@httpd.apache.org">Documentation Group</author>
      <title>Apache HTTP Server Release Guidelines</title>
    </properties>
  <body>
  
  <section><title>Introduction</title>
  <p>This document describes the general release policies used by the
  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>
  </section>
  
  <section><title>Who can make a release?</title>
  <p>Technically, any one can make a release of the source code due to the
  <a href="http://www.apache.org/LICENSE.txt">Apache Software License</a>.
  However, only members of the Apache HTTP Server Project (committers) to
  project can make a release designated with Apache.  Other people must
  call their release something other than "Apache" unless they obtain
  written permission from the Apache Software Foundation.</p>
  
  <p>Following our official release policies, we will only accept release
  binaries from members of the Apache HTTP Server Project for inclusion on our
  website.  This ensures that our binaries can be supported by members of
  the project.  Other people are free to make binaries, but we will not
  post them on our website.</p>
  </section>
  
  <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,
  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>
  </section>
  
  <section><title>Who may make a good candidate for RM?</title>
  <p>Someone with lots of time to kill.  Being an RM is a very important job
  in our community because it takes a fair amount of time to produce a stable
  release.  If you feel lucky, a release could be distributed without testing,
  but our experience has shown that leads to a higher number of <i>dud</i>
  releases.  In general, our experience has shown that a well-coordinated
  release fares better than non-coordinated releases.</p>
  </section>
  
  <section><title>When do I know if it is a good time to release?</title>
  <p>It is our convention to indicate <i>showstoppers</i> in the STATUS
  file in the repository.  A showstopper entry does not automatically
  imply that a release can not be made.  As the RM has final authority
  on what makes it into a release, they can choose to ignore the entries.
  An item being denoted as a <i>showstopper</i> indicates that the group
  has come to a consensus that no further releases can be made until the
  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>
  </section>
  
  <section><title>What power does the RM yield?</title>
  <p>Regarding what makes it into a release, the RM is the unquestioned
  authority.  No one can contest what makes it into the release.  The
  community will judge the release's quality after it has been issued,
  but the community can not force the RM to include a feature that they
  feel uncomfortable adding.  Remember that this document is only a
  guideline to the community and future RMs - each RM may run a release
  in a different way.  If you don't like what an RM is doing, start
  preparing for your own competing release.</p>
  </section>
  
  <section><title>How does an impending release affect development?</title>
  <p>It can not.  Let's repeat that: <b>an impending release can not affect
  development of the project</b>.  It is the RM's responsibility to identify
  what changes should make it into the release.  The RM may have an
  intermediate tag, so the RM can merge in or reject changes as they are
  committed to the repository's HEAD.</p>
  
  <p>Committers <i>may</i> voluntarily refrain from committing patches if
  they wish to ease the burden on the RM, but they are under
  <font color="red">no</font> obligation to do so.  This is one reason why we
  recommend that the RM have plenty of time on their hands - they may have to
  deal with a rapidly changing target.  It's not an easy job.</p>
  </section>
  
  <section><title>How can an RM be confident in a release?</title>
  <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>
  
  <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
  maintainers of apache.org's httpd instance.  In the past, the group has
  liked to see approximately 48-72 hours of usage in production to certify
  that the release is functional in the real world.  Note that some committers
  may choose to not vote on a release until feedback has been gathered from the
  apache.org instance running the release.  This is not a requirement (each
  committer is free to come up with their own personal voting guidelines),
  but it produces a feeling of confidence in the release that it will not
  be a <i>dud</i>.</p>
  </section>
  
  <section><title>How to do a release?</title>
  <p>Once the tree has been suitably tested by the RM and any other
  interested parties, they should "roll" the release.</p>
  
  <p>Key points:</p>
  <ul>
  <li>Ensure that the RM's PGP/GPG key is in the httpd-dist/KEYS file</li>
  <li>Create an official APACHE_X_Y_Z tag based of the candidate tree</li>
  <li>Run httpd_roll_release script</li>
  <li>Copy the generated release tarballs and signatures to
  daedalus:/www/httpd.apache.org/dev/dist</li>
  <li>Email dev@httpd.apache.org, current-testers@httpd.apache.org, stable-testers@httpd.apache.org
to inform them of the release.</li>
  </ul>
  </section>
  
  <section><title>What can I call this release?</title>
  <p>At this point, the release is an alpha.  The Apache HTTP Server Project
  has three classifications for its releases:</p>
  
  <ul>
  <li>Alpha</li>
  <li>Beta</li>
  <li>General Availability (GA)</li>
  </ul>
  
  <p>Alpha indicates that the release is not meant for mainstream usage or
  may have serious problems that prohibits its use.  When a release is
  initially created, it automatically becomes alpha quality.</p>
  
  <p>Beta indicates that at least three committers have voted positively
  for beta status and there were more positive than negative votes for
  beta designation.  This indicates that it is expected to compile and
  perform basic tasks.  However, there may be problems with this release
  that prohibit its widespread adoption.</p>
  
  <p>General Availability (GA) indicates that at least three committers
  have voted positively for GA status and that there were more positive
  than negative votes for GA designation.  This release is recommended
  for production usage.</p>
  </section>
  
  <section><title>Who can vote?</title>
  <p>Non-committers may cast a vote for a release's quality.  In fact,
  this is extremely encouraged as it provides much-needed feedback to
  the community about the release's quality.  However, only binding
  votes casted by committers count towards the designation.</p>
  
  <p>Note that no one may veto a release.  Releases may not receive a
  designation level if a problem is found that inhibits proper
  functionality.  The group may (implicitly or explicitly) revoke all votes
  on a release if there is a problem.  However, if there is a -1 vote for
  a particular designation and there are greater than 3 positive votes
  and more positive than negative votes (i.e. majority consensus), the
  appropriate designation is conferred upon the release.</p>
  </section>
  
  <section><title>How do we make it public?</title>
  <p>Once the release has reached the highest-available designation (as deemed
  by the RM), the release can be moved to the httpd distribution directory
  on apache.org.  Approximately 24 to 48 hours after the files have been moved,
  a public announcement can be made.  We wait this period so that the mirrors
  can receive the new release before the announcement.  An email can then be
  sent to the announcements lists (announce@apache.org,
  announce@httpd.apache.org).  Drafts of the announcement are usually
  posted on the development list before sending the announcement to let the
  community clarify any issues that we feel should be addressed in the
  announcement.</p>
  </section>
  
  <section><title>Should the announcement wait for binaries?</title>
  <p>In short, no.  The only files that are required for a public release
  are the source tarballs (.tar.Z, .tar.gz).  Volunteers can provide
  the Win32 source distribution and binaries, and other esoteric
  binaries.</p>
  
  <p>Note that the typical Win32 source distribution differs from the
  original tarball in that it has generated project files as well as
  the CRLF line endings required for that platform.  More information
  can be found <a
  href="http://httpd.apache.org/docs-2.0/platform/win_compiling.html">here</a>.
  </p>
  </section>
  
  <section><title>Oops.  We found a problem.</title>
  <p>At this point, the release has been created.  No code changes can be
  made in this release.  If a problem is found, it will have to be addressed
  in the next release or a patch can be made available.  No changes can
  be made between alpha, beta, and GA status.  The only difference is the
  file name that is downloaded by the users.  If an alpha tarball is created,
  but there was an error that can be resolved by re-rolling the tarball,
  it may be permissible to re-roll the release.  But, the code itself may
  <font color="red">not</font> change from designation to designation.</p>
  
  <p>There are two courses of action:</p>
  
  <p>Revoke the release and immediately create another one that has a fix
  to this problem.  You can take the old release, apply the single patch,
  and start the voting process again.  This is only recommended for
  critical problems found early on in the release cycle.</p>
  
  <p>If the problem is less severe, place the patch to the problem in the
  /dist/httpd/patches/apply_to_X.Y.Z directory.  A link to this directory
  should be included in the release notes with descriptions as to what
  problem each patch addresses.</p>
  </section>
  
  <section><title>Suggestions?</title>
  <p>As always, if you have any suggestions or comments on our process,
  please feel free to email our developer mailing list with your comments.
  We hope you found this document useful.</p>
  </section>
  
  </body>
  </document>
  
  
  

Mime
View raw message