DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
- 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 origin 0.10.0
- Modify the version in trunk to bump to the next one (eg. "0.10.1.0-SNAPSHOT") in the following files:
- docs/js/templateData.js
gradle.properties
committer-tools/kafka-merge-pr.py
streams/quickstart/java/pom.xml
streams/quickstart/java/src/main/resources/archetype-resources/pom.xml
streams/quickstart/pom.xml
tests/kafkatest/__init__.py
tests/kafkatest/version.py (do not add the new release version, it will only be added after the release is completed)
- .github/workflows/ci.yml
- Commit and push to trunk in apache.
- Check that the branch was correctly propagated to Apache using the webui: https://gitbox.apache.org/repos/asf?p=kafka.git
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
...
- Remember: at least 3 days, 3 +1 from PMC members (committers are not enough!) and no -1.
Send a vote closing email:
No Format To: dev@kafka.apache.org, kafka-clients@googlegroups.com, users@kafka.apache.org Subject: [RESULTS] [VOTE] Release Kafka version 0.10.0.0 This vote passes with 7 +1 votes (3 bindings) and no 0 or -1 votes. +1 votes PMC Members: * $Name * $Name * $Name Committers: * $Name * $Name Community: * $Name * $Name 0 votes * No votes -1 votes * No votes Vote thread: http://markmail.org/message/faioizetvcils2zo I'll continue with the release process and the release announcement will follow in the next few days. $RM
- Create a new tag for the release, on the same commit as the voted rc tag and push it:
- Use "git show 0.10.0.0-rc6" to find the commit hash of the tag
- git tag -a 0.10.0.0 <commit hash>
- When asked to provide a message for the new tag, to preserve uniformity in release tags, add: Apache Kafka <version number> release. For example: Apache Kafka 0.10.0.0 release
- Run "git show 0.10.0.0" and confirm that the tag points to the correct commit hash.
- git push origin 0.10.0.0
- Merge the last version change / rc tag into the release branch and bump the version to 0.10.0.1-SNAPSHOT
- git checkout 0.10.0
- git merge 0.10.0.0-rc6
- Update version on the branch to 0.10.0.1-SNAPSHOT in the following places:
- committer-tools/kafka-merge-pr.pydocs/js/templateData.js
- gradle.properties
- streams/quickstart/java/pom.xml
- streams/quickstart/java/src/main/resources/archetype-resources/pom.xml
- streams/quickstart/pom.xml
- tests/kafkatest/__init__.py (note: this version name can't follow the -SNAPSHOT convention due to python version naming restrictions, instead update it to 0.10.0.1.dev0)
tests/kafkatest/version.py
- Run "git status" and "git diff" and make sure that only the files above have changed with the intended changes. (For example, there's no .release_work_dir/ from a previous RC generation).
- git commit -a (the commit message could be "MINOR: Update 3.2 branch version to 3.2.1-SNAPSHOT")
- git push origin 0.10.0
Upload all artifacts, release notes, and docs (can be found in the .release_work_dir created by the release.py script) to https://dist.apache.org/repos/dist/release/kafka (a SVN repo, using Apache committer id/passwd).
Note Note that only PMC members can upload to the `release` directory. If the RM is not in the PMC, ask a PMC member to move them from https://dist.apache.org/repos/dist/dev/kafkathe release directory. Code Block language bash # Set your env variable for apache username APACHE_USERNAME=<apache_username> # Create the directory for release in release repo svn mkdir --username $APACHE_USERNAME -m "Making directory for 0.10.0.0" https://dist.apache.org/repos/dist/release/kafka/0.10.0.0 # Checkout the directory for the new release svn co --username $APACHE_USERNAME https://dist.apache.org/repos/dist/release/kafka/0.10.0.0 kafka-release-0-10-0-0 # Copy the artifacts from dev repo to local svn co --username $APACHE_USERNAME https://dist.apache.org/repos/dist/dev/kafka/0.10.0.0-rc0 kafka-dev-0-10-0-0 # Move files from one folder into another mv kafka-dev-0-10-0-0/* kafka-release-0-10-0-0 # Add files to SVN and commit cd kafka-release-0-10-0-0 svn --username $APACHE_USERNAME add * svn commit --username $APACHE_USERNAME -m "Release 0.10.0.0" # Update the PGP KEYS cd svn co --username $APACHE_USERNAME --depth empty https://dist.apache.org/repos/dist/release/kafka/ kafka-pgp-0-10-0-0 cd kafka-pgp-0-10-0-0 svn update KEYS wget http://kafka.apache.org/KEYS mv KEYS.1 KEYS svn commit -m "Update PGP keys"
- Make sure the KEYS file in the svn repo includes the committer who signed the release.
The KEYS must be in https://dist.apache.org/repos/dist/release/kafka/KEYS and not just in http://kafka.apache.org/KEYS. - Go to https://repository.apache.org/#stagingRepositories, find the uploaded artifacts and release them (this will push the artifacts to maven central). You will be asked to provide a description on a pop-up menu that will allow you to add Apache Kafka 0.10.0.0 (in previous descriptions you'd normally have appended the RC identifier as well).
- Wait for about a day for the artifacts to show up in apache mirror (releases, public group) and maven central (at maven.org, an example: the kafka_2.13 package).
- Release JVM based Apache Kafka Docker Image:-
- Run Promote Release Candidate Docker Image github action.
- Here the RC Docker image will be the rc docker image that got voted and approved. For example if
apache/kafka:3.7.0-rc1got voted and approved, it will be the RC docker image that needs to be used. - Promoted image will be the final release name. For 3.7.0 release it will be
apache/kafka:3.7.0 - Run the workflow and verify that the new docker image is visible on docker hub
- If this is the latest release, i.e. highest version available, then ensure that you also release for
latesttag. Which means you need to run the above pipeline again and use promoted image asapache/kafka:latest
- Release GraalVM based Native Apache Kafka Docker Image:-
- Run Promote Release Candidate Docker Image github action.
- Here the RC Docker image will be the rc docker image that got voted and approved. For example if
apache/kafka-native:3.8.0-rc1got voted and approved, it will be the RC docker image that needs to be used. - Promoted image will be the final release name. For 3.8.0 release it will be
apache/kafka-native:3.8.0 - Run the workflow and verify that the new docker image is visible on docker hub
- If this is the latest release, i.e. highest version available, then ensure that you also release for
latesttag. Which means you need to run the above pipeline again and use promoted image asapache/kafka-native:latest
- Update the supported_image_tag field in the docker_scan GitHub action. Ex.
- Update the website:
- git clone https://github.com/apache/kafka-site
- git checkout asf-site
- Verify that documentation.html (in kafka-site repo) is referring to the correct release and links.
- Verify that docs/documentation.html (in kafka repo) is similarly set up correctly.
- If it's a feature release:
- 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:
git grep "should always link the latest"| grep -v '^[0-9]'
The command grep -v '^[0-9]' excludes per-release files (e.g. ./10/documentation/streams/upgrade-guide.html)- Change these files to link to the current one.
<!--#include virtual="/36/introduction.html" -->to<!--#include virtual="/37/introduction.html" -->
- Change these files to link to the current one.
- Verify that related html files (excluding per-release files) have been updated to use the new release version by doing
git grep -Irn -A1 "should always link the latest" | grep -v '^[0-9]'
and checking that the new feature version is used. - Update files (e.g documentation.html, streams/quickstart.html) from the previous release (e.g current release is 3.7 so update files in the /36 folder) to change
'<!--//#include virtual="'...to'<!--#include virtual=".... You can find the files by runninggit grep '<!--//#include virtual='
from the directory of the previous feature release. This kafka-site PR is an example of the changes that need to be made.
- 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:
- 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.
- cf https://infra.apache.org/release-download-pages.html
- Remove the previous version from the list of "Supported Releases" in the downloads page, and move it to the "Archived Releases" section. Update the links to use "archive.apache.org" when appropriate. Ex. remove 4.1.0 from supported list when releasing 4.1.1 (PR) .
- git commit -am ".."
- git push origin asf-site
- Make sure the docs for the previous version are updated to display the "You're viewing documentation for an older version of Kafka" banner. This means un-commenting the banner out in two places: the previous version's branch of the kafka repo, and the previous version's directory in the kafka-site repo. See this commit for an example of which line displays this banner
- Send out an announcement email.
- The announcement email should be sent to announce@apache.org, users@kafka.apache.org, dev@kafka.apache.org, and kafka-clients@googlegroups.com
- You need to use your apache email address to send out the email (otherwise, it won't be delivered to announce@apache.org).
- If you use gmail, you can configure it to send outbound mail from your apache address. Go to Settings → Accounts and Import → Send mail as: , and use the config:
Server: mail-relay.apache.org Port: 587 (STARTTLS), 465 (SSL) User/Pass: {Your LDAP credentials} - For other mail clients, see https://infra.apache.org/committer-email.html
- If you use gmail, you can configure it to send outbound mail from your apache address. Go to Settings → Accounts and Import → Send mail as: , and use the config:
- You need to be subscribed to `kafka-clients@googlegroups.com` with your apache email address – otherwise it bounces back. Just send a message from your apache email to kafka-clients+subscribe@googlegroups.com and click `Join` in the confirmation email
- Make sure to send the email as plain text, if there is any html (including basic hyperlinks) the email will bounce from announce@apache.org. For gmail, removing formatting might not be enough. Make sure you've selected the option "Plain text mode".
- Double check that all the links in the email and on the downloads page work.
- Generate the release email:
- Run `release/release.py 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.
Check and update the Scala versions, if necessary, in the release email.
- Also include the kafka website blog link to the announcement email
- Example: "An overview of the release and its notable changes can be found in the release blog post:https://kafka.apache.org/blog#apache_kafka_370_release_announcement"
...
