Page History

...

1. If you have not done creating and posting your PGP key, please do by following the next instructions.
   The key must be at least 4096 bits long. 
   Publish the public key to a public PGP server
   Register its fingerprint in Apache LDAP
   scp the public key to .pgpkey under your Apache home directory
   Append the public key to the KEYS file. You can access the KEYS file via https://dist.apache.org/repos/dist/release/incubator/reef.
   Upload your public key to Apache (e.g., https://people.apache.org/keys/committer/bgchun.asc). 
   You can find useful bits from the release signing basic facts page.
   
   
2. Prepare for a source release candidate for PPMC 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.
   
   

3. 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>-incubating-rc<rc candidate number>.tar.gz.
   For example, the following commands create a release candidate and relevant files for 0.10.0 rc1.

   Code Block
   language powershell linenumbers true
   $ 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 -sha512 apache-reef-0.10.0-incubating-rc1.tar.gz > apache-reef-0.10.0-incubating-rc1.tar.gz.sha

    

   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 -sha512 apache-reef-0.10.0-incubating-rc1.tar.gz > apache-reef-0.10.0-incubating-rc1.tar.gz.sha
   
   

4. 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 members and do voting for the new release candidate. This process can iterate multiple times.
   
   
5. 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.
   
   
6. When the IPMC 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. 
    

7. In addition, the release manager should prepare for , stage and release maven artifacts. The detailed procedure is here. . Make sure to use Apache's Nexus staging repository (repository.apache.org).
   
   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 might 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 hex>"

   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.

   
   When all is set, the manager promotes should now promote maven artifacts. The artifacts should now show up immediately in the Nexus staging repositorythe maven central repo, and become available after some time in the web interface once the search index is created.
   
   
8. Don't forget to update our website with the new release download and API. Follow the steps on this page.