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

...

• 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
   1. Download
   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 
4. 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.
5. 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.
6. 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.
7. 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.

...

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:

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.  Also, create a new branch named like ozone-1.5.0 (replace the version) and push it to GitHub.

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.

...