...

1. Build the release and run unit tests. This builds a source release artifact, then builds a binary release from that source release, and runs unit tests. Auxiliary files such as MD5 checksums and the releaseaudit report are also generated by the release script.

   Code Block
   FORREST_HOME=/path/to/apache/forrest \ HCAT_RELEASE_VERSION='X.Y.Z-incubating' \ ./build-support/scripts/release.sh

2. Sign and verify signature of the release (see Step-By-Step Guide to Mirroring Releases for more information).

   Code Block
   gpg --armor --detach-sig --output build/hcatalog-src-X.Y.Z-incubating.tar.gz.asc \ build/hcatalog-src-X.Y.Z-incubating.tar.gz gpg --import KEYS (if necessarily) gpg --verify build/hcatalog-src-X.Y.Z-incubating.tar.gz.asc \ build/hcatalog-src-X.Y.Z-incubating.tar.gz

3. Copy release files to a public place (usually into public_html in your home directory):

   Code Block
   ssh people.apache.org mkdir public_html/hcatalog-X.Y.Z-incubating-candidate-0 scp -p build/hcatalog-src-X.Y.Z-incubating/build/hcatalog-X.Y.Z-incubating.tar.gz* \ build/hcatalog-src-X.Y.Z-incubating/build/releaseaudit_report.txt \ RELEASE_NOTES.txt \ people.apache.org:/home/travis/public_html/hcatalog-X.Y.Z-incubating-candidate-0

4. Call a release vote for the Podling PMC (PPMC). This vote must receive a minimum of 3 PPMC members +1s, and more +1s than -1s. The email should be sent to hcatalog-user@incubator.apache.org. The mail should:
   unmigrated-wiki-markup
   • have a subject line "\[VOTE\] Release HCatalog X.Y.Z-incubating (candidate a)" where X.Y.Z is the version number and {{a}} is the candidate number for this release.
   • State what is new in this release.
   • Tell where the keys used to sign the release can be found.
   • State where the release, md5 signature, gpg signature, and rat report can be found.
   • Request that users and developers download it, test it, and vote.
   • State when the vote closes. The vote must remain open for at least 72 hours. It can be longer at your discretion (e.g. around major holidays).
     Here is a sample email:

     Code Block

     Subject: [VOTE] Release HCatalog 0.1.0-incubating (candidate 0) Hi, I have created a candidate build for HCatalog 0.1.0-incubating. This is the initial release of HCatalog. Keys used to sign the release are available at http://svn.apache.org/viewvc/incubator/hcatalog/trunk/KEYS?view=markup. Please download, test, and try it out: http://people.apache.org/~you/hcatalog-0.1.0-incubating-candidate-0 The release, md5 signature, gpg signature, and rat report can all be found at the above address. Should we release this? Vote closes on Thursday, June 16th. Me

5. If the PPMC approves the release, call an Incubator PMC (IPMC) vote on general@incubator.apache.org. This vote must receive a minimum of 3 IPMC member +1s, and more +1s than -1s. The email sent should look similar, and include a link to the PPMC vote thread.

Publish

If both votes pass, the release needs to be published.

1. Tag the release:

   Code Block
   svn move https://svn.apache.org/repos/asf/incubator/hcatalog/tags/release-X.Y.Z-rcR \ https://svn.apache.org/repos/asf/incubator/hcatalog/tags/release-X.Y.Z -m "HCatalog X.Y.Z release."

2. Copy release files to the distribution directory and make them writable by the hcatalog group.

   Code Block
   ssh people.apache.org cp -pr public_html/hcatalog-X.Y.Z-incubating-candidate-0 /www/www.apache.org/dist/incubator/hcatalog/hcatalog-X.Y.Z-incubating cd /www/www.apache.org/dist/incubator/hcatalog chgrp -R incubator hcatalog-X.Y.Z-incubating chmod -R g+w hcatalog-X.Y.Z-incubating

3. The release directory usually contains just two releases, the most recent from two branches, with a link named 'stable' to the most recent recommended version.

   Code Block
   ssh people.apache.org cd /www/www.apache.org/dist/incubator/hcatalog rm -rf hcatalog-A.B.C-incubating; rm stable ln -s hcatalog-X.Y.Z-incubating stable

4. Wait 24 hours for release to propagate to mirrors.
5. Prepare to edit the website.

   Code Block
   svn co https://svn.apache.org/repos/asf/incubator/hcatalog/site

6. Update the front page news in : author/src/documentation/content/xdocs/index.xml.
7. Update the release news in : author/src/documentation/content/xdocs/releases.xml.
8. Update the documentation links in : author/src/documentation/content/xdocs/site.xml
9. Copy in the release specific documentation. releasedir in the following is the directory where you built the release version of HCatalog

   Code Block
   cd publish mkdir docs/rX.Y.Z cp -pr <releasedir>/build/hcatalog-X.Y.Z-incubating/docs/* publish/docs/rX.Y.Z/ svn add publish/docs/rX.Y.Z

10. We should only be publishing release specific documentation for releases still available for download. If you removed any releases from /www/www.apache.org/dist/incubator/hcatalog several steps ago, then you should also use svn rm to remove the associated documents from docs.
11. Regenerate the site, review it and commit in HowToCommit.
12. Deploy your site changes.

    Code Block
    ssh people.apache.org cd /www/incubator.apache.org/content/hcatalog svn up

13. Wait until you see your changes reflected on the Apache web site.
14. Send announcements to the user and developer lists as well as (general@haoop.apache.org) once the site changes are visible.

    Code Block
    The HCatalog team is happy to announce the release of HCatalog X.Y.Z. Apache HCatalog provides a table management service for Hadoop. More details about HCatalog can be found at http://incubator.apache.org/hcatalog. The highlights of this release are ... The details of the release can be found at http://incubator.apache.org/hcatalog/releases.html.

15. In JIRA, mark the release as released.
    1. Goto JIRA and click on Administration tab.
    2. Select the HCatalog project.
    3. Select Manage versions.
    4. Select Release for the version you have released.
    5. If a description has not yet been added for the version you are releasing, select Edit Details and give a brief description of the release.
    6. If the next version does not exist (that is, if you are releasing version 0.x, if version 0.x+1 does not yet exist) create it using the Add Version box at the top of the page.
16. In JIRA, mark the issues resolved in this release as closed.
    1. Goto JIRA and click on the "Search for Issues" on "Issues" menu.
    2. In the left hand Edit section, set Project to HCatalog.
    3. In Status select "Resolved"
    4. In Resolutions select "Fixed"
    5. Click "Search" button
    6. In the next screen, further select fix For select the version you are releasing.
    7. Click on the "Search" button
    8. Select "Tools->Bulk change all XX issues" (near the top right)
    9. Select all the issues and click on "Next"
    10. Select "Transition Issues" radio button and click on "Next"
    11. Select "Close Issue" radio button and click on "Next"
    12. Uncheck the box near the bottom at says "Send mail for this update" lest you spam every HCatalog developer with a message for every bug resolved in this release. Click "Next".
    13. Click "Confirm". Don't worry if it gives you a HTTP 500 error, it still does the transitions.
17. Update jdiff for next release (We don't have jdiff set up yet, but these next several instructions are left here so when we do we can use them)

    Code Block
    svn co https://svn.apache.org/repos/asf/incubator/hcatalog/trunk

    1. Open build.xml. Change this line:

       Code Block
       <property name="jdiff.stable" value="X.Y-1.Z"/> To <property name="jdiff.stable" value="X.Y.Z"/>

    2. Copy jdiff comparison base to trunk

       Code Block
       cp {releasedir}/lib/jdiff/hcatalog_X.Y.Z.xml lib/jdiff svn add lib/jdiff/hcatalog_X.Y.Z.xml svn remove lib/jdiff/hcatalog_X.Y-1.Z.xml svn commit -m "Jdiff change for X.Y.Z"