Skip to end of metadata
Go to start of metadata

This page is to document the release procedure for Pig. Pig is a fairly young Apache project. Its release process is work in progress and is modeled from Hadoop Release Procedure.

Note that only Pig committers can create a release.

Preparation

TODO:

  1. Define issue management process like assigning/removing issues from release.

Creating Release Branch

We only branch for major (X.0.0) and minor(X.Y.0) releases but not for patches (X.Y.Z). Patch is an update to an existing branch created for X.Y.0.

  1. Send email to dev@pig.apache.org to notify that you about to branch the tree and ask to hold off any commits till this is finished.
  2. Update CHANGES.txt to include the release version and date (use Unreleased for the date if it is unknown) and remove Trunk (unreleased changes). Below is the example of the top of the CHANGES.txt file after the update:

  3. Edit src/docs/src/documentation/content/xdocs/site.xml. In the external reference for api where the link contains the previous version number change this string to the correct version number.
  4. Commit these changes to trunk:

  5. Create a branch for the release series:

  6. Update CHANGES.txt to add back in Trunk (unreleased changes). Top of the CHANGES.txt should look like this now:

  7. Update the default version in build.xml on trunk to X.Y+1.0-dev.
  8. Commit these changes to trunk:

Updating Release Branch

The steps in this section are needed for all the releases (major, minor, and patches).

  1. Check out the branch with:

  2. Run rat report and make sure that all files that can have apache license agreement.

  3. For patches, update CHANGES.txt to include the release version and date and update site.xml with the new version. See #2 and #3 from Create Release Branch section.
  4. Update RELEASE_NOTES.txt for this release:
    1. Make sure to change all of the version number references to the current version number.
    2. Note highlights for this release. CHANGES.txt is a great place to find these.
    3. Note incompatibilities for this release. These should be listed under INCOMPATIBLE CHANGES in CHANGES.txt.
  5. Update the version number in build.xml to be X.Y
  6. Commit this changes:

  7. Tag the release candidate:

     

    Building

  1. Build and run unit tests:

  2. Check that contrib and tutorial directories compile and tests pass:

  3. Build the source release:

  4. Test the source tar file by unpacking the release and
    1. building pig.jar: ant
    2. building and running tutorial

    3. build piggybank

    4. running unit tests ant test-commit
  5. Build the convenience artifacts:

  6. Generate the MD5 checksum of the release artifact and convenience binaries:

  7. If you do not have a gpg key pair, do the following steps:
    1. Generating key pair using the following command. You can simply accept all default settings and give your name, email and Passphase.

    2. Export your public key.

    3. Open pubkey.txt, copy the full text and append it to the following files by pasting, then commit these changes:

    4. Upload updated KEYS to Apache.

    5. Export your private key, keep it with you.

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

  9. Verify gpg signature.

  10. Copy release artifact, convenience binaries, release notes and the rat report to a public place (usually into public_html in your home directory):

  11. Push proposed release to Maven staging area
    1. Create file ~/.m2/settings.xml with following contents (NOTE: It is highly recommended to use Maven's password encryption capabilities for your passwords.):

    2. Run ant command ant mvn-deploy to publish Pig artifacts to the apache snapshot repository.
    3. Run ant command ant –Drepo=staging –Dversion=X.Y.Z mvn-deploy to publish Pig artifacts to the apache staging repository.
  12. Call a release vote. The initial email should be sent to dev@pig.apache.org. Here is a sample of email:

Forward the initial email to private@pig.apache.org for Pig PMC members to vote.

Publish

Once three PMC members have voted for a release and a majority vote to release and the required 3 days have passed, it may be published.

  1. Tag the release:

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

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

  4. Push Maven release from staging to production
    1. Go to https://repository.apache.org/index.html#view-repositories;staging~browsestorage
    2. Log in, using your Apache LDAP credentials. The sign in link is in the upper right hand corner.
    3. In the frame on the left side of the page, select "Staging Repositories", you should now see a list of artifacts in the main frame.
    4. Select the appropriate artifacts for this release and click "Close" on the bar above the list of artifacts.
    5. Select the appropriate artifacts for this release and click "Release" on the bar above the list of artifacts.
  5. Wait 24 hours for release to propagate to mirrors.
  6. Prepare to edit the website.

  7. Update the front page news in author/src/documentation/content/xdocs/index.xml.
  8. Update the release news in author/src/documentation/content/xdocs/releases.xml.
  9. Update the documentation links in author/src/documentation/content/xdocs/site.xml
  10. Copy in the release specific documentation

  11. Regenerate the site, review it and commit in HowToDocument#UpdatingthePigSiteDocumentation.
  12. Wait until you see your changes reflected on the Apache web site. This might take a few minutes.
  13. Send announcements to the user and developer lists as well as (dev@pig.apache.org; user@pig.apache.org; announce@apache.org; general@hadoop.apache.org) once the site changes are visible. Note that emails sent to announce@apache.org must be sent from your apache.org email address and you must be subscribed to each of the lists.

  14. In JIRA, mark the release as released.
    1. Goto JIRA and click on Administration tab.
    2. Select the Pig project.
    3. Select 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 Add description 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 box at the top of the page.
  15. 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 Pig.
    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 Pig 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.
  16. Update jdiff for next release (step 16 to 19).

  17. Open build.xml. Change this line:

  18. Copy jdiff comparison base to trunk

  19. TODO Need to integrate javadoc into this.



Post Release

  1. Update the version number in build.xml in branch to be X.Y.N-SNAPSHOT, where N is one greater than the release being made.
  2. Commit these changes:
Labels
  • No labels