svn commit: r951974 - in /websites/staging/accumulo/trunk/content: ./ releasing.html

[bu...@apache.org]

Author: buildbot
Date: Wed May 20 02:51:54 2015
New Revision: 951974

Log:
Staging update by buildbot for accumulo

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

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed May 20 02:51:54 2015
@@ -1 +1 @@
-1680440
+1680443

Modified: websites/staging/accumulo/trunk/content/releasing.html
==============================================================================
--- websites/staging/accumulo/trunk/content/releasing.html (original)
+++ websites/staging/accumulo/trunk/content/releasing.html Wed May 20 02:51:54 2015
@@ -235,6 +235,20 @@ issue type. There is still disagreement
 the present version should be listed (including issues from former major releases); as of 1.5.1,
 it was agreed upon to omit issues from previous major versions.</p>
 <h2 id="create-the-candidate">Create the candidate</h2>
+<p><strong>TL;DR</strong></p>
+<ul>
+<li><code>./assemble/build.sh --create-release-candidate</code> to make the release candidate</li>
+<li><code>git tag $version $version-rcN</code> to create an RC tag from the actual tag</li>
+<li><code>git tag -d $version</code> make sure you don't accidentally push a "release" tag</li>
+<li><code>git push origin $version-rcN</code> push the RC tag</li>
+<li><code>git checkout -b $version-rcN-branch</code> save off the branch from the Maven release plugin</li>
+<li><strong>VOTE</strong></li>
+<li><em>If vote fails</em>, fix the original branch and start over.</li>
+<li><em>If vote passes</em>, <code>git merge $version-rcN-branch</code> back into the original branch you released from.</li>
+<li><code>git tag -s $version-rcN $version</code> make a GPG-signed tag</li>
+<li><code>git push origin $version</code> push the signed tag.</li>
+</ul>
+<p><strong>Long-winded explanation</strong></p>
 <p>You should use the provided script assemble/build.sh to create the release candidate. This script is
 desirable as it activates all necessary maven profiles in addition to verifying that certain preconditions
 are met, like RPM signing availablilty and the ability to sign files using GPG. The --test option can 
@@ -248,13 +262,6 @@ you for, as that will result in that ver
 voting to occur on artifacts that cannot be directly promoted. After the build.sh script finishes (this will 
 likely take at least 15 minutes, even on recent hardware), your current branch will be on the "next" version 
 that you provided to the release plugin.</p>
-<p>This process is likely to fail because the maven-release-plugin is not configured to push to the 
-remote repository automatically; however, this is (semi-)expected. At this point, you
-should have a local git tag for the release that you're creating. You should create a branch
-from the tag that was made by the release plugin which includes the <em>-rcN</em> suffix. This way, the branch name 
-will correctly identify which release candidate this is, while the contents of that tag will have the correct 
-versions in the pom.xml files. This also ensure that the <em>release:perform</em> goal of the release plugin will
-work as intended.</p>
 <p>One unwanted side-effect of this approach is that after creating this branch, but <em>before invoking release:perform</em>,
 you must edit the release.properties to add the <em>-rcN</em> suffix to the value of scm.tag. Otherwise, the release
 plugin will complain that it cannot find the branch for the release. With a successful invocation of <em>mvn release:perform</em>,
@@ -273,10 +280,21 @@ choose), and fix what needs fixing.</p>
 <p>If the vote passes, huzzah, you're almost done. All you need to do is to promote that stage repository
 using Nexus which you can do with the click of a button. This will trigger a process to get the release
 out to all of the mirrors.</p>
+<h2 id="copy-artifacts-to-distapacheorg">Copy artifacts to dist.apache.org</h2>
+<p>An SVN server is running at https://dist.apache.org/repos/dist/release/accumulo. You need to upload the release
+tarballs, the GPG signatures and checksum files to the correct directory (based on the release number). If you
+are releasing a bug-fix release, be sure to delete the previous release in the same line (e.g. if you release
+1.6.2, remove 1.6.1). The old tarballs removed from dist.apache.org will still be preserved in archive.apache.org
+automatically.</p>
 <h2 id="update-the-website">Update the Website</h2>
-<p>After a successful vote, this website needs to be updated with the new artifacts. The downloads page should
-be updated with the new information. A new minor release should replace the previous minor release in the major
-version. The user manual should also be updated if changes were made to it.</p>
+<p>After a successful vote, this website needs to be updated with the new artifacts.</p>
+<ul>
+<li>Copy Accumulo User Manual (HTML version exists in &gt;=1.7.0)</li>
+<li>Update downloads page</li>
+<li>Create release notes</li>
+<li>Remove previous bug-fix release (if applicable)</li>
+<li>Update examples README files</li>
+</ul>
 <h3 id="javadocs">Javadocs</h3>
 <p>Javadocs are a little convoluted to update. First off, be sure that the javadocs are <a href="http://www.kb.cert.org/vuls/id/225657">patched</a> <strong>before</strong>
 uploading as long as Java 6 is the version targeted by Accumulo (with greater than Java 7u21 being used once we