Release Manager Guide

The Apache release management process is described in the guide to release management during incubation page.

If you have not done creating and posting your PGP key, please do by following the next instructions.

Create a new key (must be at least 4096 bits long) as described at http://www.apache.org/dev/openpgp.html#generate-key.

Update Apache documents with information about your new key as described at http://www.apache.org/dev/openpgp.html#update. This article suggests a lot of places to be updated; the minimal necessary set is:
- Publish the public key to a public PGP server (http://www.apache.org/dev/release-signing.html#keyserver-upload)
- Register its fingerprint in Apache LDAP (https://id.apache.org/)
- Upload the public key to .pgpkey file in your Apache home directory. To do this, export the public key to .pgpkey file locally, ssh to <username>@people.apache.org (you have to register your SSH key at https://id.apache.org/ to be able to SSH) and use scp to do secure copy.
After this, your key will appear in the list of committers' keys at https://people.apache.org/keys/committer/ under your username.

Append your public key to the KEYS files of REEF project. Do NOT delete any old keys from the file. You can access the KEYS files via https://dist.apache.org/repos/dist/release/reef (for release) and https://dist.apache.org/repos/dist/dev/reef/ (for dev file storage). Both files are managed via SVN, so you have to svn checkout these repositories, edit KEYS in each of them and svn commit each file separately.

You can find useful information on all these steps at the release signing basic facts page.
Prepare for a source release candidate for PMC voting.
The release must not contain binary files.
The release must contain proper DISCLAIMER, NOTICE, and LICENSE files.
The source file must compile and run tests successfully.
mvn apache-rat:check passes (this is checked as part of our build process).
Create a branch for the release, e.g., branch-0.14.0. Within the branch, versions in all files must be updated to remove "-SNAPSHOT". (In contrast, the version in POMs for staging maven artifacts must contain *-SNAPSHOT. More on this later.) We have a script that can help make this change: (Run with --help to see detailed options. Python 2 is required to run these scripts)
```
python <REEF_HOME>/dev/change_version.py -s false <REEF_HOME> 0.14.0
```
Check the changes, and commit when satisfied (there is no separate code review on this stage). Then, tag the commit as a release candidate, e.g., release-0.14.0-rc1. Push these changes, making sure to also push the tag e.g, git push apache <tag_name>.
At the same time, you have to update versions in all files in master branch to next release snapshot (i.e., if you're doing release 0.14, update versions in master to 0.15). The same script helps:
```
python <REEF_HOME>/dev/change_version.py -s true <REEF_HOME> 0.15.0
```
This change should go through the same pull request/code review process as regular code changes.
Create a source release candidate gzipped tar ball, its signature (with PGP), and digests (md5 and sha512).
Here's useful info on release signing: http://www.apache.org/dev/release-signing.html.

The release candidate name is apache-reef-<version>-rc<rc candidate number>.tar.gz. Another script can take care of all of these steps: (Run with --help to see detailed options.)
```
python <REEF_HOME>/dev/release.py <REEF_HOME> 0.14.0 1 <8-letter PGP hex>
```
Make sure to run this outside of the <REEF_HOME> directory, as the artifacts will be created in the working directory. The script outputs a templated email message as well. Customize it and use it for step 6.
The artifacts should be uploaded to https://dist.apache.org/repos/dist/dev/reef/. Create a directory with the release version name and add the release, its signature, and digests. svn commit the change.
Do PMC voting at dev@reef. If the release candidate receives any -1 or does not receive three +1's, the release candidate is cancelled. The release manager should prepare for a new release candidate by fixing the problems raised by PMC members and do voting for the new release candidate. This process can iterate multiple times.
When the PMC vote passes, the release candidate becomes a release. The location of the release is under https://dist.apache.org/repos/dist/release/reef. Create a directory with the release version name and add the release, its signature, and digests.
Recent infrastructure update (after release 0.13.0): when a release vote is successful - part of the release process should become tagging the voted upon commit SHA under rel/ to make it indelible. ('# git tag rel/v15.4.2 ' or something similar.)
In addition, the release manager should prepare and release maven artifacts. The detailed procedure is here. Make sure to use Apache's Nexus staging repository (repository.apache.org). Here is a summary of necessary steps:

Create a new branch for the maven release, e.g., branch-0.14.0-maven. The version in only the POMs for staging maven artifacts must be *-SNAPSHOT. In contrast, the version in POMs for the source release must be the final release version. Again, using a script can help:
```
python <REEF_HOME>/dev/change_version.py --pomonly -s true <REEF_HOME> 0.14.0
```
The maven artifacts should be signed with the same key as the source release. Also, you must skip checkstyle to complete the build (for some reason, checkstyle wants to check generated files when running release:prepare). A command that should work is below. Try a dryRun, then remove that option when satisfied with the results.
```
$ mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true -Darguments="-DskipTests -Dcheckstyle.skip=true -Dgpg.keyname=<8-letter PGP hex>"
```
As a result of release:prepare without dryRun option, a new commit should appear at https://git-wip-us.apache.org/repos/asf?p=reef.git;a=summary with a matching tag (reef-project-0.14.0). Locally you'll see two new commits in your branch: "[maven-release-plugin] prepare release reef-project-0.14.0" and "[maven-release-plugin] prepare for next development iteration".

After this, execute release:perform, again skipping checkstyle. Note that release:prepare creates temporary files in your enlistment, including release.properties file. It contains necessary parameters for perform command; if you somehow deleted this file (for example, by running release:perform with dryRun option), re-run release:prepare with dryRun option (on a branch without two commits by maven) to re-generate the files.
```
$ mvn release:preform -Darguments="-DskipTests -Dcheckstyle.skip=true -Dgpg.keyname=<8-letter PGP hex>"
```
When all is set, the manager should now promote maven artifacts by closing the repository and then pressing Release button. The artifacts should now show up immediately in the maven central repo, and become available after some time in the web interface once the search index is created.
Don't forget to update our website with the new release download and API. Follow the steps on this page.
Push Nuget
1. Request admin permission for publishing NuGet in NuGet.org from current admin
2. Add API key in the environment variable: NuGetApiKey=f002b08a-660f-4939-9241-ca46ee4821fe
3. In release branch, double check the following settings in lang\cs\build.prop file:
    <IsSnapshot>false</IsSnapshot>
      <SnapshotNumber>00</SnapshotNumber>
      <PushPackages>false</PushPackages>
4. At \lang\cs, do a clean release build:
```
$ msbuild Org.Apache.REEF.sln /p:Configuration="Release" /p:Platform="x64"
```
  Verify the result at \lang\cs\.Nuget\packages
5. Change lang\cs\build.prop to set <PushPackages>true</PushPackages>
6. Do a clean build again with the same command at land\cs\ :
```
$ msbuild Org.Apache.REEF.sln /p:Configuration="Release" /p:Platform="x64"
```
7. Verify the result in NuGet.org

Page tree

Release Manager Guide