THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Make sure your release notes have been updated for any new commits, and go through the previous steps if necessary.
Create and publish the tag:
Code Block language text 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
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
- Setup your PGP keys for signing the release, if you don't have them already.
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
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 3D0C92B9YOUR-KEY-ID gpg: Good signature from "OwenYour O'Malley (Code signing) <omalley@apache.org>" gpg: aka "Owen O'Malley <omalley@apache.org>"Name <YOUR-APACHE-ID@apache.org>"
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
Send email to dev@hive.apache.org calling the vote.
Publish the Storage API artifacts
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
- Login to Nexus and close the repository. Mark the repository as released.
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- 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 |
Clean up Storage API artifacts
- Delete the storage-release-X.Y.Z-rcR tags
- Delete the artifacts from home.apache.org
Hive Release
Preparation
- 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:
- Unresolved JIRAs with Target Version/s or Fix Version/s (legacy) set to the release in question.
- 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).
- 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).
- 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.)
...