Page History

...

• 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

  
  

Monitor Tests

In between the branch cut and the RC cut, it's good to set up and keep an eye on the tests.
At the time of RC publishing, you will be asked to ensure you get a green run of integration tests & system tests. Due to flakes, this isn't always possible - so it's necessary to triage the tests & recognize what are flakes.

The earlier you do this, the easier it'll be later - hence this paragraph suggests you set them up now after the branch cut & start monitoring.

• The link for unit/integration tests: `https://ci-builds.apache.org/job/Kafka/job/kafka/job/{MAJOR_RELEASE_VERSION}/` - e.g https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.7/
• System tests: https://jenkins.confluent.io/job/system-test-kafka/job/3.7/<MAJOR_RELEASE_VERSION>/
  • Notable, this is hosted by Confluent.
    • If you, the RM, do not work for Confluent - contact someone from the company to set up the branch.
    • If you, the RM, do work for Confluent - set up the branch following the internal instructions in the wiki.

Create Release Artifacts

• Until

  Jira
  server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key KAFKA-12622

  is complete, you will have to manually verify the binary artifact's LICENSE file matches its own packaged dependencies. See that ticket for an example of how to do this.
• Set environment variable `PUSH_REMOTE_NAME` to the remote you want to push to, e.g., export PUSH_REMOTE_NAME=origin (default is apache-github).
• Run the `release.py` 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 pattern.
• This script will created a hidden directory called .release_work_dir. Don't delete this as you may need the contents later (for example the kafka-stream-x.x.x-test.jar)
• Troubleshooting:
  • If any step fails, make sure you have everything set up as described in the Prerequisites section and are using the correct passphrase for each config. When in doubt, remove or comment out anything in your settings that is not specifically needed for the release – for example, alternate profiles or unrelated servers, mirrors, etc in your `~/.m2/settings.xml` or `~/.gradle/gradle.properties`
  • Make sure you're running the script with Python3: sadly Python versions are not well managed especially on Macs, so you may want to explicitly invoke it with $python3 release.py 
  • Install any missing packages with pip3 , for example $pip3 install jira  – if pip can't find this, verify it's looking in the right repo by commenting out/removing any index-url settings in your ~/.pip/pip.conf 
  • Try setting an explicit path for both Java8 and Java17, rather than relying on your JAVA_HOME since this may be modified in the background by other applications (such as IDEs)

...

• git clone git@github.com:apache/kafka-site.git
• git checkout asf-site
• Update the website content including docs:
  • The gradle target releaseTarGz generates the Kafka website content including the Kafka documentation (with the exception of a few pages like project-security.html, which are only tracked in the kafka-site repository). This build target also auto-generates the configuration docs of the Kafka broker/producer/consumer/etc. from their respective Java sources. The build output is stored in ./core/build/distributions/kafka_2.13-2.8.0-site-docs.tgz.
  • Untar the file and rename the site-docs/ folder to 28/ (or, if the latter already exists, replace its contents). That's because the docs for a release are stored in a separate folder (e.g., 27/ for Kafka v2.7 and 28/ for Kafka v2.8), which ensures the Kafka website includes the documentation for the current and all past Kafka releases.
• Update the javadocs:
  • Create the release Javadocs with the gradle target aggregatedJavadoc (`./gradlew aggregatedJavadoc`) on JDK 17, with output under ./build/docs/javadoc/.
  • Copy the javadoc folder to 28/ (i.e., the full path is 28/javadoc/). If this is bug fix release, do this after the vote has passed to avoid showing an unreleased version number in the published javadocs.
    • Note that this will upload the javadocs with a version named {RELEASE_VERSION}-SNAPSHOT. Once you have an RC cut with a git tag, check out that git tag and re-generate the javadocs. That way it will not have the -SNAPSHOT  suffix anymore
• Commit & push

Blog Post

• For minor and major releases, consider writing a blog. Since the Apache blogs platform is now sunset, we've added a blog section to the Kafka website. Unfortunately this requires writing it in HTML, see the blog.html file in kafka-site.

• It's nice to thank as many people as we can identify.  Please use "Find all contributors" script to generate the list of contributors. 

• Consider incorporating any suggestions from the dev thread until release is announced

...