Child pages
  • Release Process
Skip to end of metadata
Go to start of metadata

This document describes how to release Apache Kafka from trunk. 

It is a work in progress and should be refined by the Release Manager (RM) as they come across aspects of the release process not yet documented here.

NOTE: For the purpose of illustration, this document assumes that the version being released is and the following development version will become


  • Prepare release plan in the wiki, notifying the community the overall plan and goals for the release (For example: Release Plan 0.10.0)
  • Vote on release plan: Release manager should start a vote in, asking the community to approve the release plan. 

    Subject: [VOTE] Release plan - Kafka 0.10.0
    We are starting the process to prepare for Kafka $release release. I have created release plan ($link) to cover the tasks under this release.
    If you have any JIRA in progress and would like to include it in this release, please follow the process to do so.
    Feel free to comment on the JIRA if you have any comments/suggestions.
  • Go over JIRA for the release and make sure that blockers are marked as blockers and non-blockers are non-blockers. This JIRA filter may be handy:

    project = KAFKA AND fixVersion = AND resolution = Unresolved AND priority = blocker ORDER BY due ASC, priority DESC, created ASC
  • It is important that between the time that the release plan is voted to the time when the release branch is created, no experimental or potentially destabilizing work is checked into the trunk. While it is acceptable to introduce major changes, they must be thoroughly reviewed and have good test coverage to ensure that the release branch does not start of being unstable. If necessary the RM can discuss if certain issues should be fixed on the trunk in this time, and if so what is the gating criteria for accepting them.

  • RM must have gpg keys with the public key publicly available to validate the authenticity of the Apache Kafka release: If you haven't set up gpg key, set up one using 4096 bit RSA ( Make sure that your public key is uploaded to one of the public servers ( Also, add your public key to
  • Make sure the documentation (docs/documentation.html, docs/quickstart.html,docs/api.html) are all referring to the next release and links. If this is a major or minor release #, it's a good idea to make this change now. If you end up doing it after cutting branches, be sure the commit lands on both trunk and your release branch. Note that this must be done before generating any artifacts because these docs are part of the content that gets voted on.

Cut Branches

  • Make sure you are working with a clean repo (i.e. identical to upstream - no changes in progress). If needed clone a fresh copy
  • git checkout trunk
  • Check that current HEAD points to commit on which you want to base new  release branch. Checkout particular commit if not.
  • git branch 0.10.0
  • git push apache 0.10.0
  • Check that the branch was correctly propagated to Apache using the webui:
  • Modify the version in trunk to bump to the next one "" in, tests/kafkatest/ and Commit and push to trunk in apache.
  • Create new Jenkins Build job that validates the new branch (Java 7 is enough)
  • Send email announcing the new branch:

    Subject: New release branch 0.10.0
    Hello Kafka developers and friends,
    As promised, we now have a release branch for 0.10.0 release (with
    as the version).
    Trunk has been bumped to
    I'll be going over the JIRAs to move every non-blocker from this release to
    the next release.
    From this point, most changes should go to trunk.
    *Blockers (existing and new that we discover while testing the release)
    will be double-committed. *Please discuss with your reviewer whether your
    PR should go to trunk or to trunk+release so they can merge accordingly.
    *Please help us test the release! *

Create Release Artifacts

Create a release tag - because our release branch is still but our release artifact needs to be, we'll make the change in a tag:

  • Modify the version in 0.10.0 branch to remove "-SNAPSHOT" in, and remove ".dev0" suffix in tests/kafkatest/ Commit locally, but don't push to Apache.
  • Prepare an RC tag:
    • git tag -a (this will tag the version change commit, get the rc part to match the actual rc number)
  • Move the branch head back, so future commits will still have "-SNAPSHOT"

    • git reset --hard HEAD~1
  • Push the tag to Apache (the following assumes that `apache` is the remote name for
    • git push apache

Prepare a workspace:

  • mkdir

  • cd

  • mkdir kafka-
  • git clone kafka

  • cd kafka

  • git checkout -b 0.10.0 tags/   <- important! checkout the tag, or you'll be releasing SNAPSHOT accidentally.

Check NOTICE and LICENSE files

  • Make sure the NOTICE file has the correct year

Prepare release notes

  • Go to JIRA, move all unresolved jiras with "Fix versions" of to future releases.
  • Run ./ > ../kafka- It will fail if you have any unresolved JIRAs still in the release, listing the JIRAs that still need to be addressed. Otherwise, double check that the output in RELEASE_NOTES.html looks ok for the release

Prepare the source artifact

  • git archive --format tar.gz --prefix kafka- -o ../kafka-

Prepare the binary artifacts and aggregated javadoc

  • Make sure your java is on jdk 1.7 (On mac: export JAVA_HOME=$(/usr/libexec/java_home -v 1.7))
  • Make sure you have Gradle installed
  • gradle
  • ./gradlew clean releaseTarGzAll aggregatedJavadoc
  • cp core/build/distributions/* ../kafka-
  • cp -R build/docs/javadoc ../kafka-


NOTE: as of 0.10.1 Kafka builds do not include Scala 2.12 yet, if you want to specifically create the artifacts for Scala 2.12, use  ./gradlew releaseTarGz -PscalaVersion=2.12.1

Sign the artifacts

  • Make sure you have gpg keys to sign the release artifacts
  • Sign the artifacts:
    • cd ../kafka-
    • Run the following commands (you may have to specify the gpg key to use via the `-u` option if you have multiple keys; if you forgot your key signature id, use `gpg --list-sigs <your-name>`):
      • for file in *.tgz; do gpg --armor --output $file.asc --detach-sig $file; done
        for file in *.tgz; do gpg --verify $file.asc $file; done
        for file in *.tgz; do gpg --print-md md5 $file > $file.md5; done
        for file in *.tgz; do gpg --print-md sha1 $file > $file.sha1; done
        for file in *.tgz; do gpg --print-md sha512 $file > $file.sha2; done
    • cd ..

Upload all the binary artifacts, release notes, javadoc to your URL

  • sftp can be used to copy the relevant files over to <apache_id>
    • sftp <apache_id>
    • mkdir public_html (this only needs to be done the first time)
    • cd public_html
    • mkdir kafka-
    • put -r kafka- .
  • If you find sftp is a bit clunky, lftp is an alternative

Upload artifacts to Maven staging repository

  • Go drop whatever staging repository is in the maven repo (if any):
  • Make sure you have your gpg keys (see Prerequisites section for specifics)
  • Set up ~/.gradle/ like the following. Make sure that you can login to with your apache id/passwd. The value for signing.keyId can be found by running gpg --list-secret-keys. The number after the / in the line starting with sec is your signing.keyId.

              signing.secretKeyRingFile=/Users/your-id/.gnupg/secring.gpg (if you are using GPG 2.1 and beyond, then this file will no longer exist anymore, and you have to manually create it from the new private key directory with "gpg --export-secret-keys -o ~/.gnupg/secring.gpg")

Website update process

  For new releases:

  • Make sure the documentation (docs/documentation.html, docs/quickstart.html,docs/api.html) are all referring to the correct release and links.
  • git clone
  • git checkout asf-site
  • The releaseTarGzAll target should auto-generate the configuration docs for broker/producer/consumer in ./core/build/distributions/kafka_2.11- Untar the file and rename site-docs to 0100 (or if the latter already exists, replace its contents).
  • Copy release javadoc to 0100/ (for bug-fix releases, only do this after the vote has passed to avoid showing an unreleased version number in the published javadocs)
  • If this is a major/minor release, update the list of legacy paths in includes/_header.htm
  • Commit


  • Send out a voting email to In the email, include the git revision next to the git tag (since tag will be dropped when rolling out a new RC).

    Subject: [VOTE] RC0
    Hello Kafka users, developers and client-developers,
    This is the first candidate for release of Apache Kafka This is a major release that includes: (1) New message format including timestamps (2) client interceptor API (3) Kafka Streams. Since this is a major release, we will give people more time to try it out and give feedback.
    Release notes for the release:
    *** Please download, test and vote by Monday, March 28, 9am PT
    Kafka's KEYS file containing PGP keys we use to sign the release:
    * Release artifacts to be voted upon (source and binary):
    * Maven artifacts to be voted upon:
    * Javadoc:
    * Tag to be voted upon (off 0.10.0 branch) is the tag:;a=tag;h=72fd542633a95a8bd5bdc9fdca56042b643cb4b0
    * Documentation:
    * Protocol:
    * Successful Jenkins builds for the 0.10.0 branch:
    Unit/integration tests:
    System tests:

Verification for voting

  • gpg --import KEYS (KEYS can be obtained from
  • gpg --verify foo-1.0.tar.gz.asc foo-1.0.tar.gz
  • Test at least quickstart and unit tests for all scala versions.

If need to roll a new RC

After the vote passes

  • Remember: at least 3 days, 3 +1 from PMC members (committers are not enough!) and no -1.
  • Send a vote closing email:

    Subject: [RESULTS] [VOTE] Release Kafka version
    This vote passes with 7 +1 votes (3 bindings) and no 0 or -1 votes.
    +1 votes
    PMC Members:
    * $Name
    * $Name 
    * $Name
    * $Name
    * $Name
    * $Name
    * $Name
    0 votes
    * No votes
    -1 votes
    * No votes
    Vote thread:
    I'll continue with the release process and the release announcement will follow in the next few days.
  • Create a new tag for the release, on the same commit as the voted rc tag and push it:
    • Use "git show" to find the commit hash of the tag
    • git tag -a <commit hash>
    • git push apache
  • Merge the last version change / rc tag into the release branch and bump the version to
    • git checkout 0.10.0
    • git merge
    • Update version on the branch to
    • git commit -a
    • git push apache 0.10.0
  • Mark the version as released in Kafka JIRA (from JIRA administration panel, select versions and scroll mouse towards the end of the line for the particular version. From the dropdown list, select release and set the date).
  • Upload all artifacts, release notes, and docs to (a SVN repo, using Apache committer id/passwd):
    • Only PMC members can upload to the `release` directory, so if the RM is not in the PMC, they can upload the files to instead and ask a PMC member to move them to the release directory
    • svn co kafka-release
    • create a new directory for the release (for example kafka-release/
    • copy the release artifacts from the latest RC (the ones who were in your directory) to the new release directory
    • Add the directory to SVN: svn add
    • # Optionally change KEYS file in case that you've added your key for the first time
    • svn commit -m "Release"
  • Go to, find the uploaded artifacts and release this (this will push to maven central)
  • Wait for about a day for the artifacts to show up in apache mirror and maven central.
  • Update the website:
      • Update documentation.html to include the new documentation link (e.g. 0100/documentation.html)
      • Update protocol.html to include the new protocol guide link (0100/protocol.html).
    • Update downloads.html to include the new download links from mirrors and change last release to use archive.
    • git commit -am ".."
    • git push origin asf-site
  • Send out an announcement email. You will need to use your apache email address to send out the email (otherwise, it won't be delivered to
    • Log into with your apache id.
    • Include a paragraph in the announcement email like: "According to git shortlog <number_of_contributors> people contributed to this release: <contributors>" where:
      • number_of_contributors is determined via `git shortlog -sn --no-merges <previous_release_tag>..<current_release_tag> | wc -l` (eg `git shortlog -sn --no-merges | wc -l`)
      • contributors is determined via: `git shortlog -sn --no-merges <previous_release_tag>..<current_release_tag> | cut -f2 | tr '\n' ',' | sed -e 's/,/, /g'` (eg `git shortlog -sn --no-merges | cut -f2 | sort --ignore-case | tr '\n' ',' | sed -e 's/,/, /g'`)
    • cat mail.txt|mail -s "[ANNOUCE] ..."
  • Add the release data to (must be a Kafka PMC member)


  • No labels


  1. Thanks, Joe. Do steps 21-25 publish to maven central repo? If so, should these be done after vote is closed?

    1. 21-25 publishes to apache staging repo only. Once the vote is closed successfully it is another button in nexus to push to "promote" the staged artifacts to maven central. This first step is important because it puts the artifacts in a maven repo for people to try out prior it to going to maven central and then ships exactly what was voted upon. After uploading you have to close what you uploaded for it to get staged to make sure there are no errors in the pom and such (which are not checked during the upload process) ...