Release Manual

This is a guide to make a released version of Apache RocketMQ. Please follow the steps below:


Apache Release Documentation

The release documentations provided by The ASF can be found here:

Code Signing Key

Create a code signing gpg key for release signing, use <your Apache ID> as your primary ID for the code signing key. See Apache Release Signing documentation for more details.

  • Create new pgp key. Please refer to here on how to use gpg key.
  • Generate a new key via gpg --gen-key, and answer 4096 bits with no expiration time.
  • Upload your key to a public key server by gpg --keyserver --send-key <your key id>.
  • Get the key signed by other committers(Optional).
  • Add the key to the RocketMQ KEYS file.

Tips: If you have more than one key in your gpg, set the code signing key to ~/.gnupg/gpg.conf as default key is recommended.

Prepare Your Maven Settings

Make sure your Maven settings.xml file contains the following:

    <!-- To publish a snapshot of some part of Maven -->
    <!-- To stage a release of some part of Maven -->

Tips: It is highly recommended to use Maven’s password encryption capabilities for your passwords.

Cleanup JIRA issues

Cleanup JIRA issues related to this release version, and check all the issues has been marked with right version in the FixVersion field.

Publish the Release Notes

Generate the release notes via RocketMQ JIRA and publish it to the rocketmq-site, there is a release notes of 4.0.0-incubating available for reference, include the link to the release notes in the voting emails.

Build the Release Candidate

Firstly, checkout a new branch from master with its name equal to the release version, like release-4.2.0.

Build the Candidate Release Artifacts

Before building the release artifacts, do some verifications below:

  • Make sure that your are in the candidate release branch.
  • Make sure that all the unit tests can pass via mvn clean install.
  • Make sure that all the integration tests can pass via mvn clean test -Pit-test.

Perform the following to generate and stage the artifacts:

  1. mvn clean release:clean
  2. mvn release:prepare -Psigned_release -Darguments="-DskipTests", answer the correct release version, SCM release tag, and the new development version.
  3. mvn -Psigned_release release:perform -Darguments="-DskipTests", generate the artifacts and push them to the Nexus repo. If you would like to perform a dry run first (without pushing the artifacts to the repo), add the arg -DdryRun=true

Now, the candidate release artifacts can be found in the Nexus staging repo and in the target folder of your local branch.

Tips: If you are performing a source-only release, please remove all artifacts from the staging repo besides the .zip file containing the source and the javadocs jar file. In the Nexus GUI, you can right click on each artifact to be deleted and then select Delete.

Validate the Release Candidate

Now the release candidate is ready, before calling a vote, the artifacts must satisfy the following requirements:

  • Checksums and PGP signatures are valid.
  • Build is successful including unit and integration tests.
  • LICENSE and NOTICE files are correct and dependency licenses are acceptable.
  • All source files have license headers and pass RAT checks.
  • Javadocs have been generated correctly.
  • The provenance of all source files is clear (ASF or software grants).

Please follow the steps below to verify the checksums and PGP signatures:

  1. Download the release artifacts, PGP signature file, MD5/SHA hash files.
  2. On unix platforms the following command can be executed:
  for file in `find . -type f -iname '*.asc'`
      gpg --verify ${file} 


  gpg --verify

Check the output to ensure it only contains good signatures:

  gpg: Good signature from ... gpg: Signature made ...
  1. Compare MD5, SHA hash generated by the below command with the downloaded hash files.
  gpg --print-mds 

Release Artifacts to Dev-Repository

If the release candidate passes the validation checklist, close the staging repository in Nexus by selecting the staging repository orgapacherocketmq-XXX and clicking on the Close icon.

Nexus will now run through a series of checksum and signature validations.

If the checks are passed, Nexus will close the repository and produce a URL to the closed staging repo (which contains the candidate artifacts). Include this URL in the voting email so that folks can find the staged candidate release artifacts.

If the checks aren’t passed, fix the issues then go back and restart the release process.

If everything is ok, use svn to copy the candidate release artifacts to RocketMQ repo:${release version}.

Vote on the Release

Release voting must successfully pass within the Apache RocketMQ community via the mailing list.

General information regarding the Apache voting process can be found here.

Apache RocketMQ Community Vote

To vote on a candidate release, send an email to the dev list with subject [VOTE]: Release Apache RocketMQ <release version> RC<RC Number> and body:

Hello RocketMQ Community,

This is the vote for <release version> of Apache RocketMQ.

The artifacts:${release version}

The staging repo:

Git tag for the release:
<link to the tag of GitHub repo>

Hash for the release tag:
<Hash value of the release tag>

Release Notes:
<insert link to the rocketmq release notes>

The artifacts have been signed with Key : <ID of signing key>, which can be found in the keys file:

The vote will be open for at least 72 hours or until necessary number of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

The Apache RocketMQ Team

Once 72 hours has passed (which is generally preferred) and/or at least three +1 (binding) votes have been cast with no -1 (binding) votes, send an email closing the vote and congratulate the release candidate. Please use the subject: [RESULT][VOTE]: Release Apache RocketMQ <release version> RC<RC Number> :

Hello RocketMQ Community,

The Apache RocketMQ vote is now closed and has passed with [number] binding +1s, [number] non-binding +1s and no 0 or -1:

Binding votes +1s:
User Name (Apache ID)
User Name (Apache ID)
User Name (Apache ID)

Non-binding votes +1s:
User Name (Apache ID)

The release will be published soon.

The Apache RocketMQ Team

If we do not pass the VOTE, fix the related issues, go back, restart the release process and increase RC number. When we call a new vote, we must use the updated mail subject: [RESTART][VOTE][#<Attempt Number>]: Release Apache RocketMQ <release version> RC<RC Number>

Publish the Release

Once the Apache RocketMQ PPMC votes pass, publish the release artifacts to the Nexus Maven repository and to the Apache release repository.

  1. Publish the Maven Artifacts, release the Maven artifacts in Nexus by selecting the staging repository orgapacherocketmq-XXX and clicking on the Release icon.
  2. Publish the Artifacts to the Apache Release Repository, use svn copy candidate release artifacts to${release version}

Announce the Release

Send an email to, and with the subject [ANNOUNCE] Release Apache RocketMQ <release version> and a body along the lines of:

Hi all,

The Apache RocketMQ team would like to announce the release of Apache RocketMQ <release version>.

More details regarding Apache RocketMQ can be found at:

The release artifacts can be downloaded here:${release version}

The release notes can be found here:
<insert link to the rocketmq release notes>

The Apache RocketMQ Team


Leave a Comment