accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r933249 - in /websites/staging/accumulo/trunk/content: ./ governance/releasing.html
Date Thu, 18 Dec 2014 18:18:57 GMT
Author: buildbot
Date: Thu Dec 18 18:18:56 2014
New Revision: 933249

Log:
Staging update by buildbot for accumulo

Modified:
    websites/staging/accumulo/trunk/content/   (props changed)
    websites/staging/accumulo/trunk/content/governance/releasing.html

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Dec 18 18:18:56 2014
@@ -1 +1 @@
-1645514
+1646503

Modified: websites/staging/accumulo/trunk/content/governance/releasing.html
==============================================================================
--- websites/staging/accumulo/trunk/content/governance/releasing.html (original)
+++ websites/staging/accumulo/trunk/content/governance/releasing.html Thu Dec 18 18:18:56
2014
@@ -193,36 +193,8 @@ Latest 1.5 release: <strong>1.5.2</stron
 
     <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 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>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>
-</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. 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>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>
-<li>Analyze API changes since last major release and ensure there are no changes that
will cause pain for users.</li>
-<li>Analyze and update dependencies (e.g. with mvn dependency:analyze)</li>
-<li>Test the branch as per our testing criteria.</li>
-<li>Once testing is deemed successful and release documentation is complete, move on
to Releasing.</li>
-</ol>
-<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, including a change log.</li>
-<li>Analyze and update dependencies (e.g. with mvn dependency:analyze)</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="versioning">Versioning</h2>
+<p>Accumulo has adopted <a href="/versioning.html">Semantic Versioning</a>
and follows their rules and guidelines.</p>
 <h2 id="testing">Testing</h2>
 <p>Testing for an Accumulo release includes a few steps that a developer may take without
a Hadoop cluster and several that require a working cluster. For minor releases, 
 the tests which run on a Hadoop cluster are recommended to be completed but are not required.
Running even a reduced set of tests against real hardware is always encouraged



Mime
View raw message