...
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.
Cut Branches
- 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
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
- 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
Create Release Artifacts
...
- cp core/build/distributions/* ../
- sign the artifacts:
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
Prepare java and scala docs.
- ./gradlew clean scaladoc
Upload all the binary artifacts, release notes, java and scala doc to your home.apache.org URL.
Go drop whatever staging repository may be in the maven repo
done
Prepare java and scala docs.
- ./gradlew clean scaladoc
Upload all the binary artifacts, release notes, java and scala doc to your home.apache.org URL.
Go drop whatever staging repository may be in the maven repo
- Make sure you have your gpg keys (see Pre-Requisits for specifics)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
- Set up ~/.gradle.properties like the following. Make sure that you can login to https://repository.apache.org/ with your apache id/passwd. The value for signing.keyId can be found by running "gpg --list-secret-keys --fingerprint". The number after the / in the first line is your signing.keyId.
...