This document includes information about the Storm release process.
Apache Storm follows the basic idea of Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, increment the:
Ensure you can log in to http://repository.apache.org. You should use your Apache ID username and password.
Install an svn client, and ensure you can access the https://dist.apache.org/repos/dist/dev/storm/ and https://dist.apache.org/repos/dist/release/storm/ repositories. You should be able to access these with your Apache ID username and password.
Ensure you have a signed GPG key, and that the GPG key is listed in the Storm KEYS file at https://dist.apache.org/repos/dist/release/storm/KEYS. The key should be hooked into the Apache web of trust. You should read the Apache release signing page, the release distribution page, as well as the release publishing and release policy pages.
If you are setting up a new MINOR version release, create a new branch based on master branch, e.g. 2.2.x-branch. Then on master branch, set the version to a higher MINOR version (with SNAPSHOT), e.g. mvn versions:set -DnewVersion=2.3.0-SNAPSHOT -P dist,rat,externals,examples. In this way, you create a new release line and then you can create PATCH version releases from it, e.g. 2.2.0.
Checkout to the branch to be released.
Run mvn release:prepare -P dist,rat,externals,examples followed mvn release:perform -P dist,rat,externals,examples. This will create all the artifacts that will eventually be available in maven central. This step may seem simple, but a lot can go wrong (mainly flaky tests). Note that this will create and push two commits with the commit message starting with “[maven-release-plugin]” and it will also create and publish a git tag, e.g. v2.2.0.
Once you get a successful maven release, a “staging repository” will be created at http://repository.apache.org in the “open” state, meaning it is still writable. You will need to close it, making it read-only. You can find more information on this step here.
Checkout to the git tag that was published by Step 1 above, e.g. git checkout tags/v2.2.0 -b v2.2.0. Run mvn package for storm-dist/binary and storm-dist/source to create the actual distributions.
Generate checksums for the *.tar.gz and *.zip distribution files, e.g.
cd storm-dist/source/target gpg --print-md SHA512 apache-storm-2.2.0-src.zip > apache-storm-2.2.0-src.zip.sha512 gpg --print-md SHA512 apache-storm-2.2.0-src.tar.gz > apache-storm-2.2.0-src.tar.gz.sha512 cd storm-dist/binary/final-package/target gpg --print-md SHA512 apache-storm-2.2.0.zip > apache-storm-2.2.0.zip.sha512 gpg --print-md SHA512 apache-storm-2.2.0.tar.gz > apache-storm-2.2.0.tar.gz.sha512
Create a directory in the dist svn repo for the release candidate: https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx
Run dev-tools/release_notes.py for the release version, piping the output to a RELEASE_NOTES.html file. Move that file to the svn release directory, sign it, and generate checksums, e.g.
python dev-tools/release_notes.py 2.2.0 > RELEASE_NOTES.html gpg --armor --output RELEASE_NOTES.html.asc --detach-sig RELEASE_NOTES.html gpg --print-md SHA512 RELEASE_NOTES.html > RELEASE_NOTES.html.sha512
Move the release files from Step 4 and 6 to the svn directory from Step 5. Add and commit the files. This makes them available in the Apache staging repo.
Start the VOTE thread. The vote should follow the ASF voting process.
svn mv https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx https://dist.apache.org/repos/release/dev/storm/apache-storm-x.x.x. This will make the release artifacts available on dist.apache.org and the artifacts will start replicating to mirrors.
Go to http://repository.apache.org and release the staging repository
Wait at least 24 hrs. for the mirrors to catch up.
Check out the storm-site repository, and follow the README to generate release specific documentation for the site. Compose a new blog post announcement for the new release. Update the downloads page. Finally commit and push the site as described in the storm-site README to publish the site.
Announce the new release to dev@storm.apache.org, user@storm.apache.org, and announce@apache.org. You will need to use your @apache.org email to do this.
Delete any outdated releases from the https://dist.apache.org/repos/dist/release/storm/ repository. See when to archive.
Delete any outdated releases from the storm-site releases directory, and republish the site.
Tweet, promote, celebrate. ;)
Go to http://repository.apache.org and drop the staging repository.
Delete the staged distribution files from https://dist.apache.org/repos/dist/dev/storm/
Delete the git tag.
We encourage everyone to review and vote on a release candidate to make an Apache Storm release more reliable and trustworthy.
Below is a checklist that one could do to review a release candidate. Please note this list is not exhaustive and only includes some of the common steps. Feel free to add your own tests.
dev-tools/rc to help with it;It's also preferable to set up a standalone secure Apache Storm cluster and test basic funcionalities on it.
Don't feel the pressure to do everything listed above. After you finish your review, reply to the corresponding email thread with your vote, summarize the work you have performed and elaborate the issues you have found if any. Also please feel free to update the checklist if you think anything important is missing there.
Your contribution is very much appreciated.