Skip to content

Latest commit

 

History

History
180 lines (135 loc) · 6 KB

RELEASING.adoc

File metadata and controls

180 lines (135 loc) · 6 KB
Raw

RELEASING KUDU

Overview

This document gives the steps required to perform a Kudu release, and is a resource for Kudu release managers. To edit or update this document, edit RELEASING.adoc in master.

Stating Intent to Release

  1. A week before branching: send an email to [email protected] to announce that the branch will be happening, including a deadline for when new commits will need gatekeeper approval.

  2. A day before branching: send another email to [email protected] to warn about it.

Creating the Branch

  1. Create a new branch from master:

      git checkout master
  git pull
  git checkout -b branch-0.9.x

  2. Make a note of the SHA1 for the tip of the new branch, which is the first field of the result of this command:

      git log --oneline -n1

  3. Push the branch to public remotes https://github.com/cloudera/kudu.git and http://git-wip-us.apache.org/repos/asf?p=kudu.git. The following example assumes they are called cloudera and apache.

      git push branch-0.9.x cloudera
  git push branch-0.9.x apache

  4. Create a new branch on Gerrit. Go to http://gerrit.cloudera.org:8080/#/admin/projects/kudu,branches and create a new branch with the same name and the previously-noted SHA1.

  5. Notify Todd to fix the mirroring. He will know what that means.

  6. As needed, patches can be cherry-picked to the new branch.

Updating Versions In Master

  1. Check out the master branch and bump the version in version.txt.

  2. Update the version for the Java client from within the java directory:

      cd java
  mvn versions:set -DnewVersion=0.X.0-SNAPSHOT

  3. If the python API has changed since the previous release, bump the Python version in python/setup.py in master. (the Python API uses separate versioning).

  4. After all the versions are updated, commit and push that change to Gerrit.

  5. Notify [email protected] that the new branch is available.

Preparing A Release Candidate

  1. When close to building a release candidate, try building a source tarball (on a supported platform):

      ./build-support/build_source_release.py

  2. Fix any issues it finds, such as RAT.

  3. Remove the -SNAPSHOT from the version string in version.txt.

  4. When ready, create a new lightweight tag and push it to the Apache Git repository.

      git tag 1.x.0-RC1
  git push apache 1.x.0-RC1

  5. Build a source tarball against the RC branch.

  6. Create a new folder in https://dist.apache.org/repos/dist/dev/kudu/. Copy the artifacts to this folder and commit (it is Subversion).

  svn co --depth=immediates https://dist.apache.org/repos/dist/dev/kudu/
  svn commit -m "Adding Kudu 1.x.0 RC1"

Initiating a Vote for an RC

  1. Send an email to [email protected] to start the RC process, using this example as a template.

  2. Reminder that voting on a release requires a Majority Approval by the PMC.

  3. Cycle through as many RCs as required.

  4. Always send an email with a different subject to indicate the result. For example.

  5. After the vote passes, send an email to [email protected] indicating the result.

Release

  1. Create a new folder in https://dist.apache.org/repos/dist/release/kudu/, copy the files from the release candidate’s folder in dist/dev/kudu/, then commit.

      cd kudu
  mkdir 0.9.2
  cp <path_to_rc_artifacts>/* 0.9.2
  svn add 0.9.2
  svn commit -m "Adding files for Kudu 0.9.2 RC"

  2. In the Kudu git repo, create a signed tag from the RC’s tag, and push it to the Apache Git repository:

      git tag -s 0.9.2 -m 'Release Apache Kudu 0.9.2' 0.9.2-RC1
  git push apache 0.9.2-RC1

  3. Generate the version-specific documentation from that branch following these instructions.

  4. Replace the apidocs and docs folders in the gh-pages branch with the new documentation.

  5. Update the index.md file in the releases folder, add a new folder named after the release version, copy the apidocs and docs folders there, copy an index.md file from one of the other releases and modify it accordingly.

  6. Commit all these changes.

  7. Create a new review for all those new and updated files in gh-pages.

  8. Once the review is finished and the commit is pushed, update the website.

  9. About 24 hours after the first step was completed, send an email to [email protected], [email protected], and [email protected] to announce the release. The email should be similar to [email protected]%3E">this.

  10. About another 24 hours later, delete the previous minor version in the branch you released from, from SVN. For example, if you released 1.2.1, delete 1.2.0.

  11. Update the version number on the branch you released from back to a SNAPSHOT for the next patch release, such as 0.9.2-SNAPSHOT after the 0.9.1 release.