Versions Compared

Old Version 123

changes.mady.by.user Ewen Cheslack-Postava

Saved on

compared with

New Version 124

changes.mady.by.user Ewen Cheslack-Postava

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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:

    No Format
    project = KAFKA AND fixVersion = 0.10.0.0 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 (http://www.apache.org/dev/release-signing.html). Make sure that your public key is uploaded to one of the public servers (http://www.apache.org/dev/release-signing.html#keyserver). Also, add your public key to https://github.com/apache/kafka-site/blob/asf-site/KEYS 
  • 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: https://git-wip-us.apache.org/repos/asf?p=kafka.git
  • Modify the version in trunk to bump to the next one "0.10.1.0-SNAPSHOT" in gradle.properties, tests/kafkatest/__init__.py and kafka-merge-pr.py. 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:

    No Format
    To: dev@kafka.apache.org
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 0.10.0.0
as the version).
Trunk has been bumped to 0.10.1.0-SNAPSHOT.

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! *

Thanks!

$RM

...