Page History

...

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
   language text
   svn copy https://svn.apache.org/repos/asf/hive/trunk \ https://svn.apache.org/repos/asf/hive/branches/branch-X.Y -m "Branching for X.Y releases"

3. Increment the value of the version property

   the build.properties file, hcatalog/build.properties and all

   in all pom.xml files

   (find . -name pom.xml), on trunk For

   . 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
   language text
   mvn versions:set -DnewVersion=0.8.0-SNAPSHOT -DgenerateBackupPoms=false

4. Make changes to metastore upgrade scripts. See HIVE-6555 on how this was done for HIVE 0.13
5. Verify that the build is working with changes.

6. Commit these changes to trunk.

   Code Block
   svn commit -m "Preparing for X.Y+1.0 development"

...

1. Check out the release branch with:

   Code Block
   svn co https://svn.apache.org/repos/asf/hive/branches/branch-X.Y

2. Update the version property value in

   the build.properties file, hcatalog/build.properties and hcat

   all pom.xml files

   (find hcatalog/ -name pom

   .

   xml).

   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

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

5. Commit these changes.

   Code Block
   svn commit -m "Preparing for release X.Y.Z"

6. If not already done, merge desired patches from trunk into the branch and commit these changes. We don't currently use svn merge for this, but if we did, the script would be

   Code Block
   cd branch-X.Y svn merge -rR1:R2 ../trunk . svn commit -m "Merge -r R1:R2 from trunk to X.Y branch. Fixes: HIVE-A, HIVE-B."

7. 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 JIRA's 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.)

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

   Code Block
   svn copy https://svn.apache.org/repos/asf/hive/branches/branch-X.Y \ https://svn.apache.org/repos/asf/hive/tags/release-X.Y.Z-rcR -m "Hive X.Y.Z-rcR release."

   #update the release notes in trunk with this release notes in branch.

...