Skip to content

Latest commit

 

History

History
269 lines (221 loc) · 10.3 KB

RELEASING.adoc

File metadata and controls

269 lines (221 loc) · 10.3 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-1.x.y

  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 https://gitbox.apache.org/repos/asf/kudu.git. The following example assumes they are called cloudera and apache.

      git push cloudera branch-1.x.y
  git push apache branch-1.x.y

  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. Ask someone with permissions to fix the gerrit.cloudera.org mirroring configuration. Cloudera hosts the Gerrit server and a Cloudera employee will have to perform this step because SSH access is behind a firewall. The steps are as follows:

    1. Ensure your public SSH key is in ~gerrit/.ssh/authorized_keys on gerrit.cloudera.org

    2. From behind the firewall, ssh gerrit.cloudera.org to log in.

    3. Change to the gerrit user, sudo su gerrit

    4. Back up the existing replication configuration file by executing cp ~/etc/replication.config ~/etc/replication.config.bak.`date '+%Y%m%d.%H%M%S'`

    5. Edit etc/replication.config to add a line for the new branch, such as branch-1.x.y

    6. Send email to the dev lists for Kudu and Impala ([email protected] and [email protected]) indicating that you are going to restart Gerrit (example). It is best to do the restart at some time of day when you don’t expect many people to be using the system, since Gerrit can take a few minutes to restart. 7: Restart Gerrit, ~/bin/gerrit.sh restart

  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. Commit and push that change to Gerrit.

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

Preparing A Release Candidate

  1. Before building a release candidate, make sure you have followed the Apache committer guide for setting up your GPG keys (here).

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

      ./build-support/build_source_release.py

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

  4. Test the full Java build. This will sign and build everything without deploying any artifacts:

      # Run a gpg-agent if you don't normally.
  gpg-agent --daemon
  cd java
  gradle clean install -PforceSigning

  5. Create a new version update commit which removes the -SNAPSHOT suffix (same process as above).

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

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

  7. Build a source tarball against the RC branch.

  8. Create a new folder containing the dev Subversion (SVN) repository. Copy the artifacts to this folder and commit.

      svn co --depth=immediates https://dist.apache.org/repos/dist/dev/kudu/ kudu-dev-release
  cd kudu-dev-release
  mkdir 1.x.y-RC1
  cp <path_to_kudu>/build/apache-kudu-1.x.y.tar.* 1.x.y-RC1
  svn add 1.x.y-RC1/*
  svn commit -m "Adding Kudu 1.x.y RC1"

  9. Create a Maven staging repository for the RC.

      # Run a gpg-agent if you don't normally
  gpg-agent --daemon
  cd java
  gradle clean uploadArchives -PmavenUsername="<APACHE-LDAP-USERNAME>" -PmavenPassword="<APACHE-LDAP-PASSWORD>"

    Go to the staging repository and look for ‘orgapachekudu-####’ in the staging repositories list. You can check the ‘content’ tab at the bottom to make sure you have all of the expected stuff (client, various integrations, etc). Hit the checkbox next to your new staging repo and hit “close”. Enter something similar to “Apache Kudu 1.x.y-RC1” into the description box and confirm. Wait a minute or two and hit refresh, and your staging repo should now have a URL shown in its summary tab (eg https://repository.apache.org/content/repositories/orgapachekudu-1005)

  10. Create a new folder containing the release SVN repository. For a release to be made official, it must eventually be put in this repository. Add your PGP key to the KEYS file:

    svn co https://dist.apache.org/repos/dist/release/kudu/ kudu-dist-release
cd kudu-dist-release
(gpg --list-sigs <your-email-address> && gpg --armor --export <your-email-address>) >> KEYS
svn commit -m "Adding my key to the KEYS file"

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 the release repository for the new release and copy the files from the dev repository.

      cd kudu-dist-release
  mkdir 1.x.y
  cp <path_to_kudu-dev-release>/1.x.y-RC1/* 1.x.y
  svn add 1.x.y
  svn commit -m "Adding files for Kudu 1.x.y"

  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 1.x.y -m 'Release Apache Kudu 1.x.y' 1.x.y-RC1
  git push apache 1.x.y

  3. Release the staged Java artifacts. Select the release candidate staging repository in Nexus, and click 'Release'. You should shortly be able to see the artifacts in Maven Central.

  4. Release the Python artifacts. You will need to setup an account on PyPi.org and ask to be added to the kudu-python PyPi project if you have not done this before.

    # Prepare and sign the python source distribution.
cd python
rm -rf dist/*
python setup.py sdist
gpg --detach-sign -a dist/kudu-python-1.x.y.tar.gz
# Upload the distribution to PyPi using twine.
pip install twine
twine upload dist/*

    Note: You can upload to the test PyPi by adding --repository-url https://test.pypi.org/legacy/ to the twine command.

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

  6. Update the index.md file in the releases folder, add a new folder named after the release version, copy the apidocs, cpp-client-api, and docs folders there, copy an index.md file from the previous release and modify it accordingly. Make sure the download page meets the current criteria. Base it off the latest release which has the highest chance to comform the requirements, but double-check the release pages document as the criteria keep changing and the announcement will be rejected if our release page doesn’t meet the criteria.

  7. Replace the apidocs, cpp-client-api, and docs symlinks in the gh-pages branch with links to the new documentation. Some of them may be actual directories if they had to be changed since the latest release, in this case remove the directory and link the new documentation instead.

  8. Submit these changes to the gh-pages Gerrit branch and get them reviewed.

  9. Once the review is finished and the commit is pushed, update the website following these instructions.

  10. 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 this.

  11. About another 24 hours later, clean up the SVN. If releasing a new minor version, delete the oldest minor version branch in the release repo (e.g. if 1.7.1, 1.8.0, and 1.9.0 exist and you just released 1.10.0, delete 1.7.1). If releasing a maintenance version, delete the previous maintenance branch (e.g. if you released 1.2.1, delete 1.2.0). Also delete any release candidates from the dev SVN.

  12. Update the version number on the branch you released from back to a SNAPSHOT for the next patch release, such as 1.6.1-SNAPSHOT after the 1.6.0 release.