Page History

...

1. After the release vote passes, push the artifacts to Nexus.  (If you get an error gpg: signing failed: Inappropriate ioctl for device trying doing export GPG_TTY=$(tty) .)

   No Format
   % git checkout storage-release-X.Y.Z-rcR % cd storage-api % mvn -Papache-release -DskipTests clean deploy

   
   

2. Login to Nexus and close the repository. Mark the repository as released.

3. Create the final tag (be very careful, tags in "rel/" are not changeable).

   No Format
   % git checkout storage-release-X.Y.Z-rcR % git tag -s rel/storage-release-X.Y.Z -m "Hive Storage API X.Y.Z" % git push origin rel/storage-release-X.Y.Z

   
   

4. Add the artifacts to Hive's dist area.

...

1. Check out the release branch with:

   Code Block
   language text
   git clone https://git-wip-us.apache.org/repos/asf/hive.git/ <hive_src_dir> cd <hive_src_dir> git checkout branch-X.Y

   
   

2. Update the version property value in all pom.xml files. You should remove the SNAPSHOT suffix and set version equal to hive-X.Y.Z where Z is the point release number in this release series (0 for the first one, in which case this step is a no-op since you already did this above when creating the branch). Use Maven's Versions plugin to do this as follows:

   Code Block
   language text
   mvn versions:set -DnewVersion=0.7.0 -DgenerateBackupPoms=false

   Make sure to update the version property in standalone-metastore/pom.xml and upgrade-acid/pom.xml.

3. Remove the storage-api from the list of modules to build in the top level pom.xml. Set the storage-api.version property to the release of storage-api that you are using for your release. Make sure to set the storage-api.version property in standalone-metastore/pom.xml as well.

4. Update the the value of the TRACKING_BRANCH field in the .reviewboardrc file to point to the origin/branch-X.Y.
5. Verify that the build is working with changes.

6. Commit these changes with a comment "Preparing for X.Y.Z release".

    

   
   

7. If not already done, merge desired patches from trunk into the branch and commit these changes. Avoid usage of "git merge" to avoid too many merge commits. Either request the committer who committed that patch in master to commit to this branch, or commit it yourself, or try doing a git cherry-pick for trivial patches. Specifics of this step can be laid down by the release manager.

8. You probably also want to commit a patch (on both trunk and branch) which updates README.txt to bring it up to date (at a minimum, search+replacing references to the version number). Also check NOTICE to see if anything needs to be updated for recent library dependency changes or additions.
   1. Select all of the JIRAs for the current release that aren't FIXED and do bulk update to clear the 'Fixed Version' field.
   2. Likewise, use JIRA's Release Notes link to generate content for the RELEASE_NOTES.txt file. Be sure to select 'Text' format. (It's OK to do this with a direct commit rather than a patch.)
   3. Update the release notes in trunk with the release notes in branch.

9. Tag the release candidate (R is the release candidate number, and also starts from 0):

   Code Block
   language text
   git tag -a release-X.Y.Z-rcR -m "Hive X.Y.Z-rcR release." git push origin release-X.Y.Z-rcR

   
   

...

1. Make sure your release notes have been updated for any new commits, and go through the previous steps if necessary.

2. Build the release (binary and source versions) after running unit tests. Manually create the sha256 files.

   No Format
   % mvn install -Pdist -DskipTests -Dmaven.javadoc.skip=true -DcreateChecksum=true % cd packaging/target % shasum -a 256 apache-hive-X.Y.Z-bin.tar.gz > apache-hive-X.Y.Z-bin.tar.gz.sha256 % shasum -a 256 apache-hive-X.Y.Z-src.tar.gz > apache-hive-X.Y.Z-src.tar.gz.sha256

   
   

3. Verify that the SHA 256 checksums are valid:

   No Format
   % shasum -a 256 -c apache-hive-X.Y.Z-bin.tar.gz.sha256 apache-hive-X.Y.Z-bin.tar.gz: OK % shasum -a 256 -c apache-hive-X.Y.Z-src.tar.gz.sha256 apache-hive-X.Y.Z-src.tar.gz: OK

   
   

4. Check that release file looks ok -- e.g., install it and run examples from tutorial.
5. Setup your PGP keys for signing the release, if you don't have them already.
   1. See http://www.apache.org/dev/release-signing.html, http://www.apache.org/dev/openpgp.html.

6. Sign the release (see Step-By-Step Guide to Mirroring Releases for more information).

   No Format
   % gpg --armor --output apache-hive-X.Y.Z-bin.tar.gz.asc --detach-sig apache-hive-X.Y.Z-bin.tar.gz % gpg --armor --output apache-hive-X.Y.Z-src.tar.gz.asc --detach-sig apache-hive-X.Y.Z-src.tar.gz

   
   

7. Copy release files to a public place.

   No Format
   % sftp YOUR-APACHE-ID@home.apache.org sftp> cd public_html sftp> mkdir apache-hive-X.Y.Z-rc-0 sftp> cd apache-hive-X.Y.Z-rc-0 sftp> put apache-hive-X.Y.Z*.tar.gz* sftp> quit

   
   

8. Publish Maven artifacts to the Apache staging repository. Make sure to have this setup for Apache releases.  (If you get an error gpg: signing failed: Inappropriate ioctl for device trying doing export GPG_TTY=$(tty) .)

   No Format
   % mvn deploy -DskipTests -Papache-release -Dmaven.javadoc.skip=true

   
   

9. Login to the Apache Nexus server and "close" the staged repository. This makes the artifacts available at a temporary URL.

...