This is a guide for the creation of a release of Apache Accumulo.
There are number of things that are required before attempting to build a release.
default-cache-ttl 6000
to increase the timeout from the default of 10 minutes to over an hour. If you do not have a GPG key, reference the very thorough ASF release signing documentation.Given all of this, it's recommended that you only attempt making a release from a GNU/Linux machine.
TL;DR
./assemble/build.sh --create-release-candidate
to make the release candidategit tag $version $version-rcN
to create an RC tag from the actual taggit tag -d $version
make sure you don't accidentally push a “release” taggit push origin $version-rcN
push the RC taggit checkout -b $version-rcN-branch
save off the branch from the Maven release plugingit merge $version-rcN-branch
back into the original branch you released from.git tag -s $version-rcN $version
make a GPG-signed taggit push origin $version
push the signed tag.Long-winded explanation
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 be used as a dry run for creating a release candidate. The --create-release-candidate option should be used to create the actual release candidate.
When invoking build.sh with the --create-release-candidate option, the majority of the work will be performed by the maven-release-plugin, invoking release:clean, release:prepare, and release:perform. These will guide you through choosing the correct versions. The default options provided should be what you choose. It is highly recommended that an ‘RC’ suffix is not appended to the release version the plugin prompts you for, as that will result in that version string being placed into the poms, which then would require 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.
One unwanted side-effect of this approach is that after creating this branch, but before invoking release:perform, you must edit the release.properties to add the -rcN 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 mvn release:perform, a staging repository will be made for you on the ASF Nexus server which you can log into with your ASF credentials.
After you log into Nexus, click on Staging Repositories in the Build Promotion toolbar on the left side of the screen. Assuming your build went according to plan, you should have a new staging repository made for you. At this point, you should inspect the artifacts that were staged to ensure that they are as you expect them to be. When you're ready to present those artifacts for voting, you need to close that repository which will make it publicly available for other members to inspect.
At this point, you should have a closed repository that's ready to vote on. Send a message to the dev list and get the ball rolling. If the vote ultimately fails, you delete the staged repository, clean up the branch you created (or wait until the release ultimately passes if you choose), and fix what needs fixing.
If the vote passes, huzzah, you're almost done.
Promote that staged 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.
The Git repository should also contain a tag which refers to the final commit which made up a release. This tag should also be signed with your GPG key. To ensure proper retention on release (stemming from ASF policy requirements), This final tag must being with “rel/”. For example, a release of 1.7.0 should have a corresponding tag name of “rel/1.7.0”.
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.
Fill out the [add release][addrelease] form to update the projects website.
After a successful vote, this website needs to be updated with the new artifacts.
Javadocs are easy to update. Using the latest JDK7 or later (at least JDK 7u21 to avoid known [vulnerabilities][7]), follow these steps:
mvn clean package javadoc:aggregate -DskipTests -Paggregate-javadocs
./target/site/apidocs/
master
branch of the accumulo-website repo./_devtools/git-hooks/post-commit
(if you don't have the commit hook already configured)master
and asf-site
branches back to the accumulo-website repoSome good references that explain a few things:
[6]: {{ site.baseurl }}/governance/releasing [7]: https://www.kb.cert.org/vuls/id/225657 [8]: https://www.apache.org/dev/cmsref#extpaths [addrelease]: https://reporter.apache.org/addrelease?accumulo