incubator-accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r798662 - /websites/staging/accumulo/trunk/content/accumulo/governance/releasing.html
Date Mon, 14 Nov 2011 20:19:42 GMT
Author: buildbot
Date: Mon Nov 14 20:19:42 2011
New Revision: 798662

Log:
Staging update by buildbot

Modified:
    websites/staging/accumulo/trunk/content/accumulo/governance/releasing.html

Modified: websites/staging/accumulo/trunk/content/accumulo/governance/releasing.html
==============================================================================
--- websites/staging/accumulo/trunk/content/accumulo/governance/releasing.html (original)
+++ websites/staging/accumulo/trunk/content/accumulo/governance/releasing.html Mon Nov 14
20:19:42 2011
@@ -92,20 +92,20 @@
 
   <div id="content">
     <h1 class="title">Accumulo Release Guide</h1>
-    <p>Accumulo works on a very simple cycle of major releases with the minor releases
when needed. The intent is for all major features to be implemented in a major release, with
only bug fixes and minor features being included in minor releases. API changes should intend
to only be made on major releases, with continued support of previous API for at least one
major revision. This will give user code a major revision to convert from the old API to the
new API.</p>
+    <p>Accumulo works on a very simple cycle of major releases with the minor releases
when needed. The intent is for all major features to be implemented in a major release, with
only bug fixes and minor features being included in minor releases. API changes should only
be made on major releases, with continued support of the previous API for at least one major
revision. This will give user code a major revision to convert from the old API to the new
API.</p>
 <p>Note: There will be times where API compatibility cannot be maintained, which we
understand. However, this should only be considered when there is NO other option.</p>
 <h2 id="major_release">Major Release</h2>
 <ol>
-<li>Vote to start the major release process- this should be in consensus with the community
and should be discussed on the accumulo-dev mailing list before the next steps take place.
The majority of the committers must +1 the vote and all -1s need to be discussed.<ul>
+<li>Vote to start the major release process.  This should be in consensus with the
community and should be discussed on the accumulo-dev mailing list before the next steps take
place. The majority of the committers must +1 the vote and all -1s need to be discussed.<ul>
 <li>There is not a strict time limit between major releases, but some consideration
should be made because we don't want to give our early adopters version fatigue.</li>
-<li>This will be the feature freeze for the version- Any features considered after
this call need a very strong reason for implementation, which can be discussed via mailing
list.</li>
+<li>This will be the feature freeze for the version. Any features considered after
this call need a very strong reason for implementation, which can be discussed via mailing
list.</li>
 </ul>
 </li>
-<li>Create a JIRA version for the proceeding release number- this is so we can begin
the process of noting which features are bound for the current trunk vs. a future version.</li>
-<li>Handle all JIRA tickets assigned for the current major release version- all tickets
who's version is changed should have an explanation of why they are not to be handled in the
current release.</li>
-<li>Once all JIRA tickets against the codebase (documentation tickets do not count)
are resolved/redirected, the code will be branched in SVN.<ul>
+<li>Create a JIRA version for the proceeding release number. This is so we can begin
the process of noting which features are bound for the current trunk vs. a future version.</li>
+<li>Handle all JIRA tickets assigned for the current major release version. Any ticket
whose version is changed should have an explanation of why it is not to be handled in the
current release.</li>
+<li>Once all JIRA tickets against the codebase (except documentation tickets) are resolved/redirected,
the code will be branched in SVN.<ul>
 <li>While there is currently a new trunk for the next release, it is highly discouraged
to begin committing new features to it because this is when the current release is being tested.
Any major bugs found will have to be patched in both versions and we want to make the process
as seamless as possible.</li>
-<li>New trunk needs to have it's version information updated.</li>
+<li>The new trunk needs to have its version information updated.</li>
 </ul>
 </li>
 <li>Wrap up any standing documentation endeavors, whether or not there are tickets
for them.</li>
@@ -115,27 +115,27 @@
 <h2 id="minor_release">Minor Release</h2>
 <ol>
 <li>Upon detection and/or resolution of a bug, discussion needs to be made on the accumulo-dev
list to determine if the community thinks the bug is critical or if there have been sufficient
minor bug fixes to warrant a minor release.</li>
-<li>Make any necessary documentation changes, included change log.</li>
+<li>Make any necessary documentation changes, including a change log.</li>
 <li>Test the now updated branch as per our testing criteria.</li>
 <li>Once testing is deemed successful and documentation is complete, move on to Releasing.</li>
 </ol>
 <h2 id="testing">Testing</h2>
 <ol>
-<li>All JUnit tests must pass- this should be a requirement of any patch so it should
never be an issue of the codebase.</li>
+<li>All JUnit tests must pass.  This should be a requirement of any patch so it should
never be an issue of the codebase.</li>
 <li>All functional tests must complete successfully.</li>
-<li>2 24 hour periods of the randomwalk LongClean test with and without agitation need
to be run successfully - this should be on a cluster.</li>
-<li>2 24 hour periods of continuous ingest with and without agitation needs to be validated
successfully - this should be on a cluster.</li>
-<li>2 72 hour periods of continuous ingest with and without agitation. No validation
is necessary but the cluster should be checked to ensure it's still functional - this should
be on a cluster.</li>
+<li>Two 24-hour periods of the randomwalk LongClean test with and without agitation
need to be run successfully on a cluster.</li>
+<li>Two 24-hour periods of continuous ingest with and without agitation need to be
validated successfully on a cluster.</li>
+<li>Two 72-hour periods of continuous ingest with and without agitation on a cluster.
No validation is necessary but the cluster should be checked to ensure it is still functional.</li>
 </ol>
 <h2 id="releasing">Releasing</h2>
 <ol>
 <li>Tag the tested branch. It should:<ul>
-<li>Have it's version set to note it is RC1.</li>
-<li>Be fully built, including tar.gz of the entire project as well as the documentation.</li>
+<li>Have its version set to note it is RC1.</li>
+<li>Be fully built, including a tar.gz of the entire project as well as the documentation.</li>
 </ul>
 </li>
-<li>PGP Signatures of the tarball must be signed to a separate file and made available
in the public_html folder in people.apache.org, along with the tarball and MD5 and SHA512
checksums.</li>
-<li>A vote must be made in accumulo-dev, lazy consensus is not sufficient for a release.
All checksums and signatures need to be verified before any voter can +1 it. Voting shall
last 72 hours.</li>
+<li>PGP Signatures of the tarball must be signed to a separate file and made available
in the public_html folder of the user creating the release on people.apache.org, along with
the tarball and MD5 and SHA512 checksums.</li>
+<li>A vote must be made on accumulo-dev; lazy consensus is not sufficient for a release.
All checksums and signatures need to be verified before any voter can +1 it. Voting shall
last 72 hours.</li>
 <li>Upon successful vote, the release candidate can be brought to the incubator mailing
list for approval.</li>
 <li>Upon success from the incubator list, the new releases can be retagged to remove
the RC status and released on the Accumulo webpage.</li>
 <li>If at any time the tag needs to be remade due to any sort of error, it should be
incremented to the next release candidate number. </li>



Mime
View raw message