Child pages
  • Omid Release process
Skip to end of metadata
Go to start of metadata

This document describes how to release Apache Omid from master.

It is a work in progress and should be refined by the Release Manager (RM) as they come across aspects of the release process not yet documented here.
NOTE: For the purpose of illustration, this document assumes that the version being released is and the following development version will become
NOTE: that only Omid committers can create a release.


You might need

  • gpg2
  • git client
  • svn client (yes, svn to push to dist, don't ask me why )
  • jdk7 (not 8), You will need jdk8 as well in order to deploy hbase-2 profile.
  • maven

Setting up the signing keys

Before you do a release you'll need a signing key that is registered with apache. If you already have one, you can skip this section. Otherwise, here are the steps to do:

  • Use 

    gpg2 --gen-key

    to generate a new key. Make sure that the key size is 4096 bits, the key doesn't expire

  • Now you need to register your key at using the output of

    gpg --armor --export <keyid>
  • Add your key to the KEYS file, commit, push to git
  • Upload digest to your account on (gpg2 --fingerprint)


You will need to use a gpg-agent to avoid input gpg keyphrase a million times over. On mac make install it with brew

brew install gpg-agent

Add the following line to your profile

export GPG_TTY=$(tty)

Start agent in profile or manually

eval $(gpg-agent --daemon --allow-preset-passphrase)


  • Use to check compliance of
  • Notifying the community the overall plan and goals for the release (For example: Release Plan 0.10.0). Use release template on confluence. Make sure to use JIRA filter there to display relevant issues.
  • Vote on release plan: Release manager should start a vote in, asking the community to approve the release plan.

    Subject: Release plan - Omid 0.10.0
    We are starting the process to prepare for Omid $release release. I have created release plan ($link) to cover the tasks under this release.
    If you have any JIRA in progress and would like to include it in this release, please follow the process to do so.
    Feel free to comment on the JIRA if you have any comments/suggestions.
  • Go over JIRA for the release and make sure that blockers are marked as blockers and non-blockers are non-blockers.
  • It is important that between the time that the release plan is voted to the time when the release branch is created, no experimental or potentially destabilizing work is checked into the trunk. While it is acceptable to introduce major changes, they must be thoroughly reviewed and have good test coverage to ensure that the release branch does not start of being unstable. If necessary the RM can discuss if certain issues should be fixed on the trunk in this time, and if so what is the gating criteria for accepting them.

Create Release Branch

  • Make sure you are working with a clean repo (i.e. identical to upstream - no changes in progress). If needed clone a fresh copy

    git checkout master
  • Check that current HEAD points to commit on which you want to base new release branch. Checkout particular commit if not.

    git branch 0.10.0
    git push apache 0.10.0 
  • Check that the branch was correctly propagated to Apache using the web UI
  • Switch back to master

    git checkout master
  • Modify the version in trunk to bump version to the next one "" in pom.xml-s. Either search-replace or use maven

    mvn versions:set -DnewVersion=
  • Commit and push to master in apache 

    git commit -m"[ci skip] prepare for next development iteration"
    git push apache
  • Build to validates the new branch


    git checkout 0.10.0
    mvn clean install site
  • Send email announcing the new branch


    Subject: New release branch 0.10.0
    Hello Omid developers and friends,
    We now have a release branch for 0.10.0 release (with as the version). Trunk has been bumped to
    I'll be going over the JIRAs to move every non-blocker from this release to
    the next release.
    From this point, most changes should go to trunk.
    * Blockers (existing and new that we discover while testing the release) will be double-committed. 
    * Please discuss with your reviewer whether your PR should go to trunk or to trunk+release so they can merge accordingly.

Create Release Artifacts

Because our release branch is still but our release artifact needs to be, we'll make the change in a tag:

  • Modify the version in 0.10.0 branch to remove "-SNAPSHOT" in pom.xml-s. Either search-replace or use maven

    mvn versions:set -DnewVersion=
  • Commit locally, but don't push to Apache

    git commit -a -m"[ci skip] prepare release omid-"
  •  Prepare an release candidate (RC) tag. This will tag the version change commit, get the rc part to match the actual rc number

    git tag -a
  • Move the branch head back, so future commits will still have "-SNAPSHOT"

    git reset --hard HEAD~1
  • Push the tag to Apache

    git push --tags

Prepare a public release candidate staging area

Release candidates are stored in dev-dist. You need an SVN client to manipulate Apache dev-dist. Use your apache account username. If you have not done so before, create a folder for binary staging area.

svn co <path_to>omid-dev-dist --username ikatkov

Create  sub-folder matching to current release number

mkdir <path_to>omid-dev-dist/
git clone omid
cd omid
git checkout -b 0.10.0 tags/
cp KEYS ..


Important: checkout the tag, or you'll be releasing SNAPSHOT accidentally.


  • Go to JIRA, move all unresolved jiras with "Fix versions" of to future releases.
  • Select roadmap from left panel, click on "release notes" next to the release version and prepare/format the html release notes. The html version shows up at the bottom of the page. Save the release notes as RELEASE_NOTES.html


Now prepare the source (after getting your keys local to the box)

  • Building the branch using:

    mvn clean install package -Phbase-1
  • The source tarball located in: $OMID_HOME/packaging/target/apache-omid-incubating-

  • Use to check compliance of the sources

  • sign the artifact

    gpg --armor --output apache-omid-incubating- --detach-sig apache-omid-incubating-
    gpg --print-md MD5 apache-omid-incubating- > apache-omid-incubating-
  • upload the artifacts to dist

    cd <path_to>omid-dev-dist
    rm -rf <path_to>omid-dev-dist/
    svn add --force
    svn commit --message "Omid Release" --username ikatkov
  • Check that they are there, see dev-dist
  • Validate the signatures, download the files you signed and uploaded

    mkdir temp
    cd temp/
    wget -r --no-parent
    gpg --verify apache-omid-incubating- apache-omid-incubating-
  • Update website

Stage the release artifacts to the Apache Nexus repository

Make sure that you can login to with your apache id/passwd. The value for signing.keyId can be found by running "gpg --list-secret-keys --fingerprint". The number after the / in the first line is your signing.keyId.

Edit or create ~/.m2/settings.xml introducing the values that are specific to you:

   		   <username>your apache id</username>
   		   <password>your apache password</password>
     		 <username>your apache id</username>
     		 <password>your apache password</password>
             <gpg.passphrase>your GPG password</gpg.passphrase>

    See for details on encrypting the passwords rather than leaving them in the clear.

    Run the following on the release branch

mvn deploy -Phbase-1 -Papache-release -DskipTests

Apache Nexus

Enter Apache Nexus and do the following:

  • Click on Log In in the upper right corner. Log in using your apache user name and password.
  • In the left navigation pane, select Staging Repositories.
  • Identify the release candidate you just pushed, by your user name (in parentheses as part of the "Repository" name) and the "Created On" date.
  • Click on the check box to the left of your Repository name to select it.
  • [Optional] If you accidentally click on the Repository name itself, another tab will pop open. If so, just close it.
  • Click the Close button above the Repository names. This makes your release candidate available at the Staging level. 
  • The artifacts should show up under with correct file modification dates.
  • If you have previously staged an older release candidate with the same version number, and it is still showing in the Repository list, you must select and Drop the old one now.  

PMC Voting

Send out a voting email to

Subject: [VOTE] Omid release branch

Here's the Apache Omid release candidate #0 now available for a vote
within dev community.

Links to various release artifacts are given below. Please review and vote.

The vote will be open for at least 72 hours and until necessary number of
votes are reached.
[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

Release notes for the release:

Git tag for the release:;a=tag;h=72fd542633a95a8bd5bdc9fdca56042b643cb4b0

Sources for the release:

Source release verification:
  PGP Signature:

  MD5 Hash:

  Keys to verify the signature of the release artifact are available at:

Remember: at least 3 days, 3 +1 from PMC members (committers are not enough!) and no -1.

Verification for voters: 

  • gpg --import KEYS (KEYS can be obtained from KEYS)
  • gpg --verify foo-1.0.tar.gz.asc foo-1.0.tar.gz
  • Run at least unit tests

If need to roll a new RC

  • Go back to the beginning  - don't forget to bump the RC number.

Consolidate Vote Result

Send out a vote results email to

Subject: [RESULT][VOTE] Omid release branch

Hi All,

After being open for over 72 hours, the vote for releasing Omid passed with n binding +1s and no 0 or -1. 
Binding +1s:

I am going to create a vote in the general@ list.

Incubator vote:

  • Once PMC vote pass, initiate a vote in incubator. Send vote email to incubator-general

    Subject: [VOTE] Release Apache Omid (incubating)
    The Apache Omid community has voted on and approved a proposal
    to release Apache Omid
    PPMC Vote Call:
    PPMC Vote Result:
    PPMC Vote Summary:
    3 binding (IPMC member) +1 votes
    1 non-binding PPMC member +1 votes
    No -1 votes
    Git tag for the release:;a=tag;h=72fd542633a95a8bd5bdc9fdca56042b643cb4b0
    Sources for the release:
    Source release verification:
      PGP Signature:
      MD5 Hash:
      Keys to verify the signature of the release artifact are available at:
    We request the permission of IPMC to publish the above release candidate as
    Apache Omid Please try out the package and vote.
    The vote is open for a minimum of 72 hours or until the necessary number of
    votes (3 binding +1s) is reached.
    [ ] +1 Release this package as Apache Omid
    [ ]  0 I don't feel strongly about it, but I'm okay with the release
    [ ] -1 Do not release this package because...
    Please add (binding) if your vote is binding.

    Remember: at least 3 days, 3 +1 from incubator PMC (vote from Omid PMC can carry over if he's also incubator PMC) and no -1.

After the incubator vote passes:

  • Merge the last version change / rc tag into the release branch
  • Update version on the branch to
  • Send a vote closing email

    Subject: [RESULTS] [VOTE] Omid release branch
    This vote passes with 8 +1 votes (4 bindings) and no 0 or -1 votes.
    +1 votes
    PMC Members:
    * $Name
    * $Name 
    * $Name
    * $Name
    * $Name
    * $Name
    * $Name
    0 votes
    * No votes
    -1 votes
    * No votes
    Vote thread:
    I'll continue in the release process and announce a release in the next few days.

Publish Release Artifacts

  • Check in source tarball to Dist
svn co <path_to>omid-dist --username ikatkov
mkdir <path_to>omid-dist/
cd ..
svn add
svn commit --message "Omid Release" --username ikatkov
  • Push Maven release from staging to production
    1. Go to;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
  • Wait 24 hours for release to propagate to mirrors.
  • Update the website TODO

  • Send announcements email

    Subject: Omid Released
    The Omid team is happy to announce the Omid release.
    The highlights of this release are ...
  • In JIRA, mark the release as released.
    1. Goto JIRA and click on Administration tab.
    2. Select the Omid 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.
  • 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.
  • No labels