Versions Compared

Old Version 61

changes.mady.by.user Vaibhav Gumashta

Saved on

compared with

New Version 62

changes.mady.by.user Owen O'Malley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleHadoop Version Warning

This page assumes you are releasing from the master branch, and thus omits the use of Maven profiles to determine which version of Hadoop you are building against. If you are releasing from branch-1, you will need to add -Phadoop-2 to most of your Maven commands.

Storage API releases

The Hive projects has two products that are released separately:

  1. Storage-API - the vectorization and predicate push down classes
  2. Hive - the rest of Hive

Most Hive releases will require a new storage-api release and the storage-api currently releases faster than hive, so has higher version numbers.

Storage API Prepare Master Branch

Skip this section if this is NOT the first release in a series (i.e., release X.Y.0).

  1. Check out the master branch

    Code Block
    languagetext
    git checkout master

  2. Increment the value of the version property in the storage-api/pom.xml file. For example, if the current value is 2.5.0-SNAPSHOT, the new value should be 2.6.0-SNAPSHOT. Please note that the SNAPSHOT suffix is required in order to indicate that this is an unreleased development branch.

  3. Update the storage-api.version property in the root pom.xml to the new value from the step above.

  4. Verify that the build is working with changes.

  5. Commit these changes to master with a comment "Preparing for storage-api X.Y+1.0 development".

Storage API Branching

Skip this section if this is NOT the first release in a series (i.e., release X.Y.0).

  1. Notify developers on the #hive IRC channel and dev@hive mailing lists that you are about to branch a release.

  2. Create a branch for the release series: 

    Code Block
    languagetext
    git checkout -b storage-branch-X.Y origin/master

  3. Update the version property value in the storage-api/pom.xml file. You should remove the SNAPSHOT suffix and set version equal to 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:

  4. Verify that the build is working with changes.

  5. Commit these changes with a comment "Preparing for storage-api X.Y.Z release".

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

    Code Block
    languagetext
    git commit -a -m "Preparing for storage-api X.Y.Z release"
git push -u origin storage-branch-X.Y
git tag -a storage-release-X.Y.Z-rcR -m "Hive Storage API X.Y.Z-rcR release."
git push origin storage-release-X.Y.Z-rcR

Making Storage API Release Artifacts

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

  2. Create and publish the tag:

    Code Block
    languagetext
    git tag storage-release-X.Y.Z-rcR -m "Hive Storage API X.Y.Z-rcR release."
git push origin storage-release-X.Y.Z-rcR

  3. Build the release (binary and source versions) after running unit tests. Manually create the sha file.

    No Format
    % wget https://github.com/apache/hive/archive/storage-release-X.Y.Z-rcR.tar.gz
% tar xzvf storage-release-X.Y.Z-rcR.tar.gz
% mv storage-release-X.Y.Z-rcR/storage-api hive-storage-X.Y.Z
% tar czvf hive-storage-X.Y.Z-rcR.tar.gz hive-storage-X.Y.Z
% shasum -a 256 hive-storage-X.Y.Z-rcR.tar.gz > hive-storage-X.Y.Z-rcR.tar.gz.sha256
  4. 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.

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

    No Format
    % gpg --armor --detach-sig hive-storage-X.Y.Z-rcR.tar.gz

  6. Check the signatures

    No Format
    % shasum -c hive-storage-X.Y.Z-rcR.tar.gz.sha256
hive-storage-X.Y.Z-rcR.tar.gz: OK

 
% gpg hive-storage-X.Y.Z-rcR.tar.gz.asc
gpg: assuming signed data in `hive-storage-X.Y.Z-rcR.tar.gz'
gpg: Signature made Fri Apr 28 12:50:03 2017 PDT using RSA key ID 3D0C92B9
gpg: Good signature from "Owen O'Malley (Code signing) <omalley@apache.org>"
gpg:                 aka "Owen O'Malley <omalley@apache.org>"

  7. Copy release files to a public place.

    No Format
    % sftp YOUR-APACHE-ID@home.apache.org

sftp> cd public_html
sftp> mkdir hive-storage-X.Y.Z
sftp> cd hive-storage-X.Y.Z
sftp> put hive-storage-X.Y.Z-rcR.tar.gz*
sftp> quit

  8. Send email to dev@hive.apache.org calling the vote.

  9. After the release vote passes, push the artifacts to Nexus

    No Format
    % git checkout storage-release-X.Y.Z-rcR
% cd storage-api
% mvn -Papache-release -DskipTests clean deploy
  10. Login to Nexus and close the repository. Mark the repository as released.

Preparation

  1. Bulk update Jira to unassign from this release all issues that are open non-blockers and send follow-up notification to the developer list that this was done. There are two kinds of JIRAs that need to be taken care of:
    1. Unresolved JIRAs with Target Version/s or Fix Version/s (legacy) set to the release in question.
    2. Resolved/closed(!) JIRAs with Target Version/s, but not Fix Version/s set to the release in question (e.g. a JIRA targets 2.0.0 and 1.3.0, but was only committed to 2.0.0).
  2. Run 'mvn clean apache-rat:check' and examine the generated report for any files, especially .java files which should all have Apache license headers. Note also, that each individual component will have a rat.txt inside it when you run this – be sure to check ql/target/rat.txt, for example. Add the license header to any file that is missing it (open a jira and submit a patch).
  3. Update copyright date in NOTICE. If any components mentioned in them have updated versions, you would need to update the copyright dates for those. (Thejas comment: It sounds like entries are needed in NOTICE only if the license requires such attribution. See http://www.apache.org/legal/src-headers.html#notice.)

...

  1. Notify developers on the #hive IRC channel and dev@hive mailing lists that you are about to branch a release.

  2. Create a branch for the release series: 

    Code Block
    languagetext
    git checkout -b branch-X.Y origin/master
git push -u origin branch-X.Y

  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.

  4. Increment the value of the version property in all pom.xml files. For example, if the current value is 0.7.0-SNAPSHOT, the new value should be 0.8.0-SNAPSHOT. Please note that the SNAPSHOT suffix is required in order to indicate that this is an unreleased development branch. This can be accomplished with a single command using Maven's Versions plugin as follows: 

    Code Block
    languagetext
    mvn versions:set -DnewVersion=X.Y.0-SNAPSHOT -DgenerateBackupPoms=false
  5. Make changes to metastore upgrade scripts. See HIVE-6555 on how this was done for HIVE 0.13.
  6. Verify that the build is working with changes.

  7. Commit these changes to master with a comment "Preparing for X.Y+1.0 development".

...