Page History

...

1. If you have not done creating and posting your PGP key, please do by following the next instructions.
   The
   Create a new key (must be at least 4096 bits long. 
   Publish ) 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
   Register (http://www.apache.org/dev/release-signing.html#keyserver-upload)
   - Register its fingerprint in Apache LDAP
   scp (https://id.apache.org/)
   - Upload the public key to .pgpkey under 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.
   Append the 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 You can access the KEYS file files via https://dist.apache.org/repos/dist/release/incubator/reef.
   Upload your public key to Apache (e.g.,  (for release) and https://peopledist.apache.org/repos/dist/keysdev/committer/bgchun.asc). 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 bits from information on all these steps at the release signing basic facts page.
   
   
2. Prepare for a source release candidate for PPMC PMC voting.
   The release must not contain binary files. 
   The release must contain proper DISCLAIMER, NOTICE, and  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).
   
   

3. 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)
   

   Code Block
   language text
   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>.
   
   

4. 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:
   

   Code Block
   language text
   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.
   
   

5. Create a source release candidate gzipped tar ball, its signature (with PGP), and digests (md5

   , sha1,

   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>

   -incubating

   -rc<rc candidate number>.tar.gz.

   
   For example, the following commands create a release candidate and relevant files for 0.10.0 rc1.
   tar cfz apache-reef-0.10.0-incubating-rc1.tar.gz apache-reef-0.10.0-incubating-rc1
   gpg --armor -u <public key id (8 hex numbers)> --output apache-reef-0.10.0-incubating-rc1.tar.gz.asc --detach-sig apache-reef-0.10.0-incubating-rc1.tar.gz 
   openssl dgst -md5 apache-reef-0.10.0-incubating-rc1.tar.gz > apache-reef-0.10.0-incubating-rc1.tar.gz.md5
   openssl dgst -sha1 apache-reef-0.10.0-incubating-rc1.tar.gz > apache-reef-0.10.0-incubating-rc1.tar.gz.sha1
   openssl dgst -sha512 apache-reef-0.10.0-incubating-rc1.tar.gz > apache-reef-0.10.0-incubating-rc1.tar.gz.sha512
   In addition, the release manager must prepare for maven artifacts. The detailed procedure is here. 

   Note. After the first release, most of the information needed in POMs are set correctly. The version in POMs for staging maven artifacts must be *-SNAPSHOT. In contrast, the version in POMs for the source release must be the final release version.
   The release manager can handle the differences between source release and maven artifacts by creating two release branches. 

   Another script can take care of all of these steps: (Run with --help to see detailed options.)

   Code Block
   language text
   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.

    

6. Do PMC Do PPMC 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 PPMC PMC members and do voting for the new release candidate. This process can iterate multiple times.
   Do IPMC voting at general@incubator. The voting email should contain the PPMC voting result thread. If at least three IPMC members cast +1 binding votes (with no -1 vote), the vote passes. If not, the release manager should prepare for a new release candidate and do PPMC and IMPC voting.
   
   
7. When the IPMC 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/incubator/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. (e.g., 'git tag rel/0.14.0') 
    

8. In addition, the

   manager promotes maven artifacts in the Nexus staging repository.

   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:

   Code Block
   language text
   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.

   Code Block
   language text
   $ 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.

   Code Block
   language text
   $ mvn release:perform -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.
   
   
9. Don't forget to update our website with the new release download and API. Follow the steps on this page.
10. 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.props file:

           <IsSnapshot>false</IsSnapshot>

           <SnapshotNumber>00</SnapshotNumber>

           <PushPackages>false</PushPackages>

    4. At \lang\cs, do a clean release build:

       Code Block
       language text
       $ msbuild Org.Apache.REEF.sln /p:Configuration="Release" /p:Platform="x64"

       Verify the result at \lang\cs\.Nuget\packages 

    5. Change lang\cs\build.props to set <PushPackages>true</PushPackages> 

    6. Do a clean build again with the same command at lang\cs\ :

       Code Block
       language text
       $ msbuild Org.Apache.REEF.sln /p:Configuration="Release" /p:Platform="x64"

       
       

    7. Verify the result in NuGet.org