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 0.10.0.0 and the following development version will become 0.10.1.0
NOTE: that only Omid committers can create a release.
You might need
- 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.
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:
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 http://pgp.mit.edu/ using the output of
- Add your key to the KEYS file, commit, push to git
- Upload digest to your account on id.apache.org (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
Add the following line to your profile
Start agent in profile or manually
- Use http://compliance.rocks/ 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 email@example.com, asking the community to approve the release plan.
- 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
Check that current HEAD points to commit on which you want to base new release branch. Checkout particular commit if not.
- Check that the branch was correctly propagated to Apache using the web UI
Switch back to master
Modify the version in trunk to bump version to the next one "0.10.1.0-SNAPSHOT" in pom.xml-s. Either search-replace or use maven
Commit and push to master in apache
- Build to validates the new branch
- Send email announcing the new branch
Create Release Artifacts
Because our release branch is still 0.10.0.0-SNAPSHOT but our release artifact needs to be 0.10.0.0, 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
Commit locally, but don't push to Apache
Prepare an release candidate (RC) tag. This will tag the version change commit, get the rc part to match the actual rc number
Move the branch head back, so future commits will still have "-SNAPSHOT"
Push the tag to Apache
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.
Create sub-folder matching to current release number
Important: checkout the tag, or you'll be releasing SNAPSHOT accidentally.
- Go to JIRA, move all unresolved jiras with "Fix versions" of 0.10.0.0 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:
The source tarball located in: $OMID_HOME/packaging/target/apache-omid-incubating-0.10.0.0-src.tar.gz
Use http://compliance.rocks/ to check compliance of the sources
sign the artifact
upload the artifacts to dist
- Check that they are there, see dev-dist
Validate the signatures, download the files you signed and uploaded
Stage the release artifacts to the Apache Nexus repository
Make sure that you can login to https://repository.apache.org/ 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:
See http://maven.apache.org/guides/mini/guide-encryption.html for details on encrypting the passwords rather than leaving them in the clear.
Run the following on the release branch
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 https://repository.apache.org/content/groups/staging/org/apache/omid 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.
Send out a voting email to firstname.lastname@example.org
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 email@example.com
Once PMC vote pass, initiate a vote in incubator. Send vote email to incubator-general
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 0.10.0.1
Send a vote closing email
Publish Release Artifacts
- Check in source tarball to Dist
- Push Maven release from staging to production
- Go to https://repository.apache.org/index.html#view-repositories;staging~browsestorage
- Log in, using your Apache LDAP credentials. The sign in link is in the upper right hand corner.
- 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.
- Select the appropriate artifacts for this release and click "Close" on the bar above the list of artifacts.
- 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
- In JIRA, mark the release as released.
- Goto JIRA and click on Administration tab.
- Select the Omid project.
- Select Versions.
- Select Release for the version you have released.
- 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.
- 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.
- Goto JIRA and click on the "Search for Issues" on "Issues" menu.
- In the left hand Edit section, set Project to Pig.
- In Status select "Resolved"
- In Resolutions select "Fixed"
- Click "Search" button
- In the next screen, further select fix For select the version you are releasing.
- Click on the "Search" button
- Select "Tools->Bulk change all XX issues" (near the top right)
- Select all the issues and click on "Next"
- Select "Transition Issues" radio button and click on "Next"
- Select "Close Issue" radio button and click on "Next"
- 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".
- Click "Confirm". Don't worry if it gives you a HTTP 500 error, it still does the transitions.