Versions Compared

Old Version 140

changes.mady.by.user Owen Nichols

Saved on

compared with

New Version 141

changes.mady.by.user Owen Nichols

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titlePermission and Keys:
  • Ensure that the release manager is (or will be able to work with) a Geode PMC member (needed at svn checkout step in prepare_rc).
  • Ensure that the release manager has bulk modification permissions on Apache Geode JIRA.

To verify

    1. Go to : https://issues.apache.org/jira/secure/Dashboard.jspa→ login → Issues → Search for Issues → select Geode in the Project list
    2. After logging in, on the top right side of the page click on Tools → Bulk Change → Current Page
    3. Select any ticket and click Next
    4. The Transition Issue option should not be blocked as N/A. If it is not blocked means that you have bulk operation permission.
    5. You will also need admin permissions to manage releases in Jira.  To check, see if you can see an Add button on https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
    6. If you don't have permissions, send a mail requesting permission to dev@geode.apache.org.
  • Ensure that the release manager has permission to modify the wiki for the release docs : Release Notes
    1. If you don't have permissions, send a mail requesting permission to dev@geode.apache.org.
  • Ensure that the release manager has Docker Hub credentials with permission to upload Apache Geode to Docker Hub. To get permissions follow the steps below
    1. If you don't have a docker hub account create one at https://hub.docker.com/
    2. After creating the docker hub ID, send an email to dev@geode.apache.org requesting access to upload Apache Geode artifacts to Docker Hub mentioning your docker id.
  • Ensure that the release manager has a valid pgp key.  Make sure to keep your gpg passphrase in a safe place (you will need it again later).  The email address associated with your gpg key must be your @apache.org email address. 
    1. For MacOS use https://gpgtools.org/
    2. For Ubuntu https://askubuntu.com/questions/100281/how-do-i-make-a-pgp-key
    3. Ensure that the public key is published and uploaded to servers.
      1. Add the key fingerprint to https://id.apache.org under OpenPGP Public Key Primary Fingerprint. The fingerprint can be found in the GPG Keychain in MacOS or the second line of the command executed in step a.
      2. Upload your public key into ALL of the following keyservers:
        1. http://pool.sks-keyservers.net:11371
        2. http://keyserver.ubuntu.com:11371
        3. gpg --send-keys 8_digit_fingerprint
          gpg --keyserver pgp.mit.edu --send-keys 8_digit_fingerprint
          gpg --keyserver keyserver.ubuntu.com --send-keys 8_digit_fingerprint
    4. Ask a fellow committer to co-sign your key. Note: it may take several hours or overnight before other's can "see" that your key has been uploaded, and as along again for you to see that they signed it, so start this process early.
  • Add the release manager's public key block to the KEYS file in develop branch, if they are not already present in it.

    1. On MacOS : (More information available at https://www.apache.org/dev/release-signing.html#basic-facts)

      Code Block
      languagebash
      titleOn MacOS terminal
      (gpg --list-sigs <your name> && gpg --armor --export <your name>) >> keys.log


    2. Take the contents of keys.log and append it to KEYS file in the develop branch of Apache Geode. Commit and push to origin.

    3. Sample key block which needs to be appended to the KEYS file in develop:

      No Format
      pub   rsa4096 2018-01-04 [SC] [expires: 2022-01-04]
      CE6CD0A89480B1B9FCB98699274C66710770C135
uid           [ultimate] Nabarun Nag <nag@cs.wisc.edu>
sig 3        274C66710770C135 2018-01-04  Nabarun Nag <nag@cs.wisc.edu>
sig 3        C8D3705F9DBE2177 2018-02-26  Jason Huynh <jasonhuynh@apache.org>
sub   rsa4096 2018-01-04 [E] [expires: 2022-01-04]
sig          274C66710770C135 2018-01-04  Nabarun Nag <nag@cs.wisc.edu>

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFpOogwBEADlT2Ue6XDFHqbM/LbZXhHMw4rcT4ifuBGyibbUbhLWGimav5tI
buGRxOViV2q5FNIEYK6Gyfr1kKTlBxCZxkmbNj5lyqgBM7HfL0sTQ2kGd9IE7rPz
KQ65yzUdKd4Aacm9Zlfja6pV6vYbMBdd4gcGFfsobh4yD0dZFXBlkEiqKV89PhxG
h9PaBFN6FfDYTaUwir2MveV54N5ynPKcVt9Ler5v6wo/1Mr+bxoZ5dy15UMqxgHT
YfRDGmLvCPjI0Aabc86bzgi8FJ8QdW1/oBLH/fjDardQOSgGCI7Smz4F52LGXb7Z
.
.
.
Y79TWNoe0dBLf6B8dmX+aqfWhziCz2Ijy8lF8sfQl2DalG+YpBkBBsNs8j/6lpHr
Fgh2AddGmNuaP+tMFGCtdeHujkSbx7b1UOkxgLTS7nsRM0l6QN4czTNYcaUFgVU4
Ig==
=VFqr
-----END PGP PUBLIC KEY BLOCK-----


  2. Check that git is configured with your apache email address
    1. check current email: git config user.email
    2. set to apache if necessary: git config --global user.email your_apache_ldap_username@apache.org
  3. In GitHub, from drop-down menu in top-right of screen:
    1. under Settings > Emails > Add email address, add your apache email address (and check your inbox for verification link)
    2. paste your public key block (same what you put in KEYS file) into GitHub under Settings > SSH and GPG keys > New GPG Key

...

Determine release type

A major release is a version x.0.0

A minor release is a version x.y.0 where y > 0

A patch release is a version x.y.n where n > 0

Except where noted, all instructions in this guide apply to both all three types of releases.  The most common Geode release type is minor (a new major version would only be for breaking changes, and would ideally be preceded by some major discussion on the dev list).  

Announce intent to branch (major/minor only)

Geode nominally cuts support branches for new minor releases on a time-based schedule (Monday on or after Feb 1, May 1, Aug 1, Nov 1), unless otherwise decided on the dev list.  A week or two before the scheduled date, send a [DISCUSS] email to dev@geode.apache.org proposing that a new support branch be created.  Remind the community that only critical fixes will be allowed once the support branch is created, so it is helpful to have develop as stable as possible before branching.

...

  1. cd .. && ./geode/dev-tools/release/license_review.sh -v HEAD -p 1.12.0 (replace 1.12.0 with the version of the previous release) to check the LICENSE files for missing dependencies or outdated versions and compare dependencies against a previous release.  If any dependencies were removed, manually check for stale references in LICENSE or NOTICE files that can be removed.  If new dependencies were added that have Apache 2.0 License, add them to the license_review script's isApache2 function.  If a new 3rd-party .jar is now appearing in the binary distribution, update geode-assembly/src/main/dist/LICENSE appropriately.   If new 3rd-party intellectual property was checked into the source tree (e.g. a javascript library), update both LICENSE and geode-assembly/src/main/dist/LICENSE.

Branching for release

Create the support branches (major/minor only)

  1. From one directory above a checkout of latest geode develop, run the create_support_branches script.  This will create branches on all projects and update version numbers appropriately, and guide you though creating the support pipeline, updating Jira, and creating a PR to bump develop to the next version.

    Code Block
    languagebash
    cd ..
geode/dev-tools/release/create_support_branches.sh -v 1.13 -g your_github_username


  2. Review the benchmark baseline on the support branch.  It should usually be {previous release} 

    See ci/pipelines/shared/jinja.variables.yml around line 20 (under benchmarks:)

    Code Block
    languageyml
       baseline_version: '1.12.0'


  3. Send email to dev@geode.apache.org informing the creation of the support branch and requesting feedback.

    No Format
    Hello Geode Dev Community,

We have created a new support branch for Apache Geode {x.y.0} - "support/{x.y}"

Please focus your acceptance testing on this branch and raise any concerns in the next few weeks.  After some quiet period we will package a release candidate and begin voting upon it.

Regards
{Release Manager}


  4. For the duration of the release process, continue to monitor the new release pipeline and address any issues that may arise, including analyzing any test failures (ask for volunteers on the dev list to investigate any failures you are unsure of).

Bump the version of the develop branch (major/minor only)

  1. The create_support_branches script already walked you through creating the PR for this, adding the new version to Jira, and bumping the pipeline version on develop.  (note: you must be in the Jira Administrators group to see the Add button in Jira; request permission on the dev list if you don't see it).

...