Page History

This document describes the process to release Apache Ozone. The process is not yet scripted, and the documentation is a work in progress

...

1. Install a program to prompt you for your gpg key passphrase (example using homebrew): brew install pinentry-mac 
2. Tell git to use this program for signing: git config --global gpg.program "$(which pinentry-macgpg)"
3. Tell git which key to sign with: git config --global user.signingKey <gpg_key_id>
4. Tell gpg to use this program to prompt for passphrase: echo "pinentry-program $(which pinentry-mac)" > ~/.gnupg/gpg-agent.conf 
5. Reload gpg-agent: gpgconf --kill gpg-agent 

...

• Build the Release Tarballs. Make sure that Hugo is installed so that this step will also build the documentation. Also make sure you are using GNU-tar instead of BSD-tar.

mvn clean install -Dmaven.javadoc.skip=true -DskipTests -Psign,dist,src -Dtar -Dgpg.keyname="$CODESIGNINGKEY"

...

1. Extract the contents of the source tarball and build it with an empty maven cache by renaming your ~/.m2 directory before doing the build.
2. Check the size of the output binary tarball for significant size increase from the last release.
   1. The Apache servers currently have a limit of 350mb for release artifacts.
   2. A significant increase in size could indicate a dependency issue that needs to be fixed.
   3. The Apache svn repo has a size limit for release artifacts. If uploading svn fails because the tarball is too big, we need to contact INFRA to increase our repo size. See here for details.
3. Verify signatures
   Verify signatures
   1. Download the KEYS file from  https://dist.apache.org/repos/dist/release/ozone/KEYS
   2. Import its contents (which should include your public gpg key): gpg --import KEYS 
   3. Verify each .tar.gz artifact: gpg --verify <artifact>.tar.gz.asc <artifact>.tar.gz 
   1. Verify checksums
      1. Run shasum -a 512 *.tar.gz 
      2. Verify that the output checksums for each artifact match the contents of its .sha512 file and the SHA512 line in its .mds file.
   2. Make sure docs are present in the release tarball
      1. There should be a directory called docs in the top level. If there is not, then hugo  was not installed during the build and it must be re-done.
      2. Extract the release and open docs/index.html in your web browser, and check that the documentation website looks ok.
   3. Check the output of running  bin/ozone version  from the extracted release tarball
      1. After extracting the release, the output of this command should contain:
         1. The correct release
         2. The correct national park tag
         3. A non-snapshot version of Ratis.
         4. A link to the apache/ozone GitHub repository (not your fork).
         5. The git hash of the last commit the release was built on.
   4. Run the Ozone upgrade acceptance tests by running test.sh  from the compose/upgrade directory in the extracted release tarball.
      
      1. This check is also run by the GitHub actions CI for each commit, so it should pass with no surprises.

   ...

   • Link to the release candidate tag on Github
   • Link to a Jira query showing all resolved issues for this release. Something like this.
   • Location of the source and binary tarballs. This link will look something like https://dist.apache.org/repos/dist/dev/ozone/1.2.0-rc0/
   • Location where the maven artifacts are staged. This link will look something like https://repository.apache.org/content/repositories/orgapacheozone-1001/
   • Link to the public key used to sign the artifacts. This should always be in the KEYS file and you can just link to that: https://dist.apache.org/repos/dist/dev/ozone/KEYS
   • Fingerprint of the key used to sign the artifacts.

   ...

   Code Block
   svn checkout https://dist.apache.org/repos/dist/dev/ozone cd ozone svn mkdir "$VERSION" cp "$RELEASE_DIR"/* "$VERSION"/ svn add "$VERSION"/* svn commit -m "Added ozone-$VERSION directory"

   ...

   PMC members can move it to the final location:

   Code Block
   svn mv -m "commit msg" https://dist.apache.org/repos/dist/dev/ozone/"$VERSION" https://dist.apache.org/repos/dist/release/ozone/"$VERSION"

   ...

   1. Cherry pick your commit updating the protolock files to a branch on your fork, and merge it to master with a pull request.
   2. Update the Ozone SNAPSHOT version and national park tag on master with a pull request. Here you will pick the national park to use for the next release of Ozone and set it in the project's top level pom at /project/properties/ozone.release<ozone.release>. Example

   Update the Ozone Roadmap

   ...

   The Ozone docker image is intended for testing purposes only, not production use. Therefore, it is ok to update this after announcing the release. An example pull request to update the docker image is here. The target branch for your pull request should be latest. After the pull request is merged, it can be published to docker hub by fast-forwarding the ozone-latest branch to match the latest branch.

   Patch Release

     Also, create a new branch named like ozone-1.5.0 (replace the version) and push it to GitHub.

   Code Block
   language bash
   git checkout ozone-latest git pull git merge --ff-only origin/latest git checkout -b "ozone-${VERSION}" git push origin ozone-latest "ozone-${VERSION}"

   
   

   Patch Release

   If there is a security vulnerability or critical bug uncovered in a major or minor Ozone release, a patch release may be necessary to fix this. The process is a bit simpler than a major or minor release, since there is already a solid foundation on the release's maintenance branch.

   ...

   In the event of a critical security vulnerability or seriously harmful bug with a small set of changes in the patch, PMC members may vote to forgo the usual 72 hour minimum time for a release vote and publish once there are enough binding +1s. 

   Remove the previous patch release from Apache distribution site:

   Code Block
   language bash
   svn rm -m 'Ozone: delete old version 1.2.0' https://dist.apache.org/repos/dist/release/ozone/1.2.0

   Update this document

   After finishing the release process, update this page to fix any mistakes, unclear steps, or outdated information.

   ...