Child pages
  • HowToRelease

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Trivial edits for storage API

...

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

...

Release

The Hive projects has two products that are released separately:

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

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

...

  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 

...

  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.htmlhttp://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 YOUR-KEY-ID
    gpg: Good signature from "Your Name <YOUR-APACHE-ID@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.

...

Publishing the Storage API

...

Artifacts

  1. 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
  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.
No Format
% svn checkout https://dist.apache.org/repos/dist/release/hive hive-dist
% cd hive-dist
% mkdir hive-storage-X.Y.Z
% cd hive-storage-X.Y.Z
% wget http://home.apache.org/~YOUR-APACHE-ID/hive-storage-X.Y.Z/hive-storage-X.Y.Z-rcR.tar.gz{,.sha256,.asc}
% svn add .
% svn commit

...

Cleaning Up Storage API

...

Artifacts

  1. Delete the storage-release-X.Y.Z-rcR tags.
  2. Delete the artifacts from home.apache.org.

Hive Release

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.)

...