layout: page title: Livy - Release Process tagline: Release Process

{% include JB/setup %}

Preparing Livy Releases

Note: This document is a work in progress and is not guaranteed to be a comprehensive release guide

Overview

The release manger for a Apache Livy release is in charge of:

  1. Cut and update branches and tags
  2. Create and publish release distros and artifacts to staging locations
  3. Call a vote to authorize release
  4. Publish the release (once a vote passes)
  5. After the release is complete

Prepare for release

If this is your first release it may be useful to read some of the following:

  • Apache Software Release Documentation
  • Apache Incubator Podling Release Policies
  • Apache Guide on Signing Releases
  • The Apache Spark Release Guide (for comparison)

Cut and update branches and tags

  1. Create new branch (from master if a major/minor version, or branch-X.x for a maintenance version for version X.x) then push it to apache.
  2. Update the master branch with to the next version if this is a major/minor release. (Example commit)
  3. Remove SNAPSHOT from the version on branch then cut rc1 tag. (Example commit)
  4. After cutting the rc1 tag you can then update the branch with the next maintenance version. (Note: If you do this prior to release any changes between rc’s will be individually cherry-picked) (Example commit)

Create and publish release distros and artifacts to staging locations

  1. Make sure your public key is in the KEY file in the Livy Dist. Directions for creating your key for releases can be found here.
  2. Publish the release archives to the Apache dev dist for dev testing (these will be moved to the release dist after a successful vote).
    1. Set env variables as described in dev/release-build.sh (or utilize the script's prompts).
    2. Run dev/release-build.sh package (Note: You may need to run GPG_TTY=$(tty); export GPG_TTY for the script to work).
    3. Double check the distros has been uploaded to the dev dist.
  3. Use dev/release-build.sh publish-release to push the release artifacts to the apache staging repo (Note: Make sure sha1 is installed before running the script). Double check that the artifacts were published successfully by checking the staging repo.

Call a vote to authorize release

  1. Email the Livy dev mailing list to call for vote on the release candidate and make sure to note that if it passes it will go to an official vote on the Incubator general mailing list. (Example email)
  2. If the vote passes email the Incubator general list to call for a PMC vote. (Example email). If the vote fails, address the issues raised and cut a new rc with the required fixes.

Publish the release (once a vote passes)

  1. Go to the staging repo, select the livy repo from the publish-release step above and click the “release” button at the top of the page to release the new Livy version artifacts.
  2. Move the contents of the dev dist to the release dist (removing the rc# from the folder name).
    1. Example steps
      $ svn co https://dist.apache.org/repos/dist/dev/incubator/livy/
$ export SVN_EDITOR=vim
$ svn mv https://dist.apache.org/repos/dist/dev/incubator/livy/0.5.0-incubating-rc2/ https://dist.apache.org/repos/dist/release/incubator/livy/0.5.0-incubating/
    2. If you updated the KEYS file during this release make sure you also copy that as well.
  3. Checkout the rc git tag and recommit it without the rc# (Example below)
    $ git tag -a v0.5.0-incubating -m "Apache Livy 0.5.0-incubating"
$ git push --delete apache v0.5.0-incubating-rc1
  4. Announce the release to the Incubator general, Livy dev, and Livy user mailing lists (Example Email), if you want you can complete the website update step below to include links in the email.

After the release is complete

  1. Open a PR to update the website with the new latest version number, release notes, and a copy of the Docs built using the new release.
  2. If there were any non-blocking issues raised during the vote make sure there are open JIRAs to address them in the next release.