accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r951974 - in /websites/staging/accumulo/trunk/content: ./ releasing.html
Date Wed, 20 May 2015 02:51:55 GMT
Author: buildbot
Date: Wed May 20 02:51:54 2015
New Revision: 951974

Staging update by buildbot for accumulo

    websites/staging/accumulo/trunk/content/   (props changed)

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

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
 it was agreed upon to omit issues from previous major versions.</p>
 <h2 id="create-the-candidate">Create the candidate</h2>
+<li><code>./assemble/ --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><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>
+<p><strong>Long-winded explanation</strong></p>
 <p>You should use the provided script assemble/ to create the release candidate.
This script is
 desirable as it activates all necessary maven profiles in addition to verifying that certain
 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 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 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</h2>
+<p>An SVN server is running at
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 will still be preserved
 <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>
+<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>
 <h3 id="javadocs">Javadocs</h3>
 <p>Javadocs are a little convoluted to update. First off, be sure that the javadocs
are <a href="">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

View raw message