This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

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)

  • 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 docs/documentation.html is 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

Skip this section if you are releasing a bug fix version (e.g. 2.2.1).

  • 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/, tests/kafkatest/, streams/quickstart/pom.xml, streams/quickstart/java/pom.xml, and streams/quickstart/java/src/main/resources/archetype-resources/pom.xml. Commit and push to trunk in apache. This is also needed in the non-trunk branch for a bug-fix release.
  • Modify the DEFAULT_FIX_VERSION to in in the trunk branch. This is not needed in the non-trunk branch for bug-fix release.
  • Create new Jenkins Build job that validates the new branch (Java 8 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

  • Run the `` script in the root of the kafka repository and follow the instructions. NOTE that if you are releasing a version prior to 1.0.x, you need to have minor edits on the script to change the three-digits pattern checking to four-digits parttern.

Website update process

We should improve the release script to include these steps. In the meantime, for new releases:

  • Make sure the documentation.html is 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 (If this is bug fix release, do this after the vote has passed to avoid showing an unreleased version number in the published javadocs)
  • Commit

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):
  • 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 files (e.g. documentation.html, protocol.html, quickstart.html, intro.html) to include the link for the new version (e.g. 0100/documentation.html). The full list of files can be found by `grep "should always link the the latest"` and exclude those per-release files (e.g. ./10/documentation/streams/upgrade-guide.html)
      • Verify that related html files (exlcluding per-release files) have been updated to use the new release version by doing `grep -A1 "should always link the the latest" . -Irn` and checking that the new feature version is used.
    • Update downloads.html to include the new download links from mirrors and change last release to use archive. Also add a paragraph with a brief feature introduction for the release.
    • Update index.html "Latest News" box
    • 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
    • Run  `./ release-email` script in the root of the kafka repository and follow the instructions to generate the announcement email template for the release to the mailing list.
      (or)  follow below instruction to generate the email content.
      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'`)
    • Log into with your apache id.
    • cat mail.txt|mail -s "[ANNOUNCE] ..."
      • note: you need to be subscribed to `` with you apache email address – otherwise it bounces back

      • Use the previously generated email template using `` script (or) Use the below email template (maybe update Scala versions accordingly):

        The Apache Kafka community is pleased to announce the release for Apache Kafka <release-number>.
        This is a bug fix release and it includes fixes and improvements from <#> JIRAs, including a few critical bugs.
        All of the changes in this release can be found in the release notes:
        You can download the source and binary release (Scala 2.11 and Scala 2.12) from:
        Apache Kafka is a distributed streaming platform with four core APIs:
        ** The Producer API allows an application to publish a stream records to one or more Kafka topics.
        ** The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
        ** The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
        ** The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.
        With these APIs, Kafka can be used for two broad classes of application:
        ** Building real-time streaming data pipelines that reliably get data between systems or applications.
        ** Building real-time streaming applications that transform or react to the streams of data.
        Apache Kafka is in use at large and small companies worldwide, including Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank, Target, The New York Times, Uber, Yelp, and Zalando, among others.
        A big thank you for the following <#> contributors to this release!
        We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at
        Thank you!
  • The PMC member who committed the release artifacts to the SVN dist repository should add the release data to (they will get a notification asking them to do this after the svn commit).
  • PMC member should double check if older releases should be archived (cf. This includes updating `download.html`
  • File a JIRA for updating compatibility/upgrade system tests to test the newly released version. Example PRs:
  • For major releases, consider writing a blog in If you don't have a blog account, just log into once with your Apache credential and notify the Kafka PMC chair, who can then invite you to the blog space. Follow the instructions for creating a preview.  Send the preview to dev mailing for comments before publishing.

  • 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) ...