This article contains all the steps required to release Apache Geode. 

Before you begin

Software dependencies

1. git →  https://git-scm.com/downloads
2. docker → https://docs.docker.com/docker-for-mac/install/ svn → shipped with MacOS [install with command line tools → https://stackoverflow.com/questions/9329243/xcode-install-command-line-tools]
3. gpg tools → https://gpgtools.orgweb browser → 
4. java JDK8 → https://support.google.com/chrome/answer/95346?co=GENIE.Platform%3DDesktop&hl=en
5. java JDK → https://docs.oracle.com/javase/8/docs/technotes/guides/install/install_overview.html
6. text editor : vi → should be pre-installed
7. adoptopenjdk.net Make sure you have the latest patch release of OpenJDK 1.8.0 (not Oracle JDK).
8. Homebrew → https://brew.sh/
9. svn → [on Mac, brew install svn]Homebrew → https://brew.sh/
10. fly → use platform-appropriate download link in bottom right corner of https://concourse.apachegeode-ci.info. Do it this way, not with homebrew, so you get the version that matches concourse.
11. cmake, doxygen, and openssl - install using an appropriate package manager, e.g. on Mac: cmake, doxygen, and openssl - install with brew on mac ( brew install doxygen && brew install cmake && brew install openssl
12. jinja → pip3 install Jinja2
13. PyYAML → pip3 install PyYAML
14. text editor (vi or whatever you prefer)
15. web browser

Permission and keys

...

Info
title Permission and Keys:
Ensure that the release manager has bulk modification permissions on Apache Geode JIRA. To verify 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 Go to Go to : https://issues.apache.org/jira/secure/Dashboard.jspa→ login → Issues → Search for Issues → select Geode in the Project list After logging in, on the top right side of the page click on Tools → Bulk Change → Current Page Select any ticket and click Next The Transition Issue option should not be blocked as N/A. If it is not blocked means that you have bulk operation permission. If you don't have permissions, send a mail requesting permission to dev@geodeYou 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 If you don't have permissions, send a mail requesting permission to dev@geode.apache.org. Ensure that the release manager has permission to Ensure you have permission to modify the wiki for the release docs : Release NotesThe release manager will need to have a Docker Hub credential that has permission to upload Apache Geode to Docker Hub. To get permissions follow the steps below If you don't have a docker hub account create one at permissions, send a mail requesting permission to dev@geode.apache.org. Ensure that the release manager has permission to deploy pipelines to Geode CI (you need to be able to login to https:// hub concourse. docker.com/After creating the docker hub ID, send an email apachegeode-ci.info AND send a request to dev@geode.apache.org requesting access  requesting concourse permissions for your login) Ensure that the release manager has Docker Hub credentials with permission to upload Apache Geode artifacts to Docker Hub mentioning your docker id. . To get permissions follow the steps below If you don't have a docker hub account create one at Ensure that you have a valid pgp key. For MacOS use https://gpgtools.org/For Ubuntu https://askubuntuhub.docker.com/questions/100281/how-do-i-make-a-pgp-key Ensure that the public key is published and uploaded to servers. Ask a fellow committer to co-sign the keys. This ensures that the keys are available on public servers. It takes awhile for the key uploads to mirrors. This must happen before a key can be co-signed.  If you are using GPG Tools >= 2.1, export your secret key to a file to be used by Gradle. You can export it with `gpg --export-secret-keys >~/.gnupg/secring.gpg` Add your public key block to KEYS file in develop branch if they are not already present in it. 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.  For MacOS use https://gpgtools.org/ For Ubuntu https://askubuntu.com/questions/100281/how-do-i-make-a-pgp-key Ensure that the public key is published and uploaded to servers. 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. Upload your public key into ALL of the following keyservers: http://pool.sks-keyservers.net:11371 http://keyserver.ubuntu.com:11371 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 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. On MacOS : (More information available at https://www.apache.org/dev/release-signing.html#basic-facts) Code Block language bash title On MacOS terminal (gpg --list-sigs <your name> && gpg --armor --export <your name>) >> keys.log Take the contents of keys.log and append it to KEYS file in the develop branch of Apache Geode. Commit and push to origin. On MacOS : (More information available at https://www.apache.org/dev/release-signing.html#basic-facts) Code Block language bash title On MacOS terminal (gpg --list-sigs <your name> && gpg --armor --export <your name>) >> keys.log Take the contents of keys.log and append it to KEYS file in the develop branch of Apache Geode. Commit and push to origin. Also, 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. Also upload your public key into keyserver http://pool.sks-keyservers.net:11371 http://keyserver.ubuntu.com:11371 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-----

Info
title Discussion on JIRAs
Send a [DISCUSS] email to dev@geode.apache.org informing developers that a new release branch is about to be created. Request developers to respond back if they are waiting to finish a JIRA issue, or feel that a particular JIRA / fix must be included in the release. Request they also confirm that the Geode LICENSE and NOTICE files been confirmed to accurately reflect what is on develop.  Once this discussion comes to a conclusion and everything that is necessary for the release is present in the develop branch we start with creating the release branch.

Creating the release branch:

Terminology

A major release is a version x.0.0 and allows/implies breaking changes, removal of deprecated methods, changes to minimum JDK, etc. 

A minor release is a version x.y.0 where y > 0 and typically allows/implies new features.

A patch release is a version x.y.n where n > 0 and should contain a limited number of critical fixes only.

Except where noted, all instructions in this guide apply to all three types of releases.  Dev list proposals for patch releases may be made at any time since the branch already exists, however some planning ahead is helpful for major or minor releases. since it is usually desirable to cut the branch a couple months in advance. 

Propose cutting a support branch (major/minor only)

Send a [DISCUSS] email to dev@geode.apache.org proposing that a new support branch be created.

Review LICENSE and NOTICE files

Confirm that the Geode LICENSE and NOTICE files on develop are accurate (ask for help on the dev list if needed).  This is best done before cutting the branch, otherwise be sure to backport any changes to the support branch as well.

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
   language bash
   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
   language yml
   baseline_version: '1.12.0'

   
   

3. Send email to dev@geode.apache.org informing the creation of the support branch and any rules for backporting changes to the branch

4. Check for the most recent develop SHA that passes all the tests and contains all the features / bug fixes that need to go into the release at https://concourse.apachegeode-ci.info/beta/teams/main/pipelines/develop/jobs/UpdatePassingRef.
5. Ensure in JIRA, that all tickets with {version} as the fix version are either closed or resolved. If not inform the the assignees to either resolve/close it or if not fixed then increment the fix version in the ticket

Create the release branch.

Code Block
language bash
git checkout develop git checkout -b release/{version}

6. Update the version number in gradle.properties (and remove -SNAPSHOT)

7. Update the version number in ci/pipelines/geode-build/jinja.template.yml

8. Change SNAPSHOT to "" for SEMVER_PRERELEASE_TOKEN in ci/pipelines/meta/meta.properties

9. Update the version number in all the expected pom files use these steps:

   Code Block
   language bash
   ./gradlew clean ./gradlew build -Dskip.tests=true #note: ok if build fails expected pom test ./gradlew updateExpectedPom

    

10. Review the benchmark baseline.  It should be the more recent of {previous release} or develop/highwater.  branch should stay as develop even for release branches.  Note: as the release progresses, consider creating and using a dedicated version/highwater tag on the release branch.

    See ci/pipelines/shared/jinja.variables.yml around line 19:

    Code Block
    language yml
    benchmarks: baseline_branch: develop/highwater baseline_version: '' branch: develop

    Publish the release branch to origin

    Code Block
    language bash
    git add . git commit -a -m "Upgraded version number for releasing {version}" pit push origin HEAD

    Now checkout the repo for geode-examples (apache/geode-examples.git) and create a release branch.

    Code Block
    language bash
    git clone git@github.com:apache/geode-examples.git git checkout develop origin/develop git checkout -b release/{version}

    Update the version number in gradle.properties of geode-examples and remove -SNAPSHOT

    No Format
    version = 1.7.0 geodeVersion = 1.7.0

    Commit the version changes and push the release branch of geode-examples

    Code Block
    language bash
    git add -p git commit git push origin HEAD

    Checkout the repo for geode-native (apache/geode-native.git) and create a release branch

    Code Block
    language bash
    git checkout develop git checkout -b release/{version} git push origin HEAD

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

    No Format

    Hello Geode Dev Community, We have created a new releasesupport branch for Apache Geode {versionx.y.0} - "releasesupport/{versionx.y}" Please do reviewfocus your acceptance testing on this branch and raise any concernconcerns within the next releasefew branchweeks. If noany concernschanges are needed raised,please we will start with the voting for the release candidate soon. Regards {Release Manager}

    Create the concourse release pipeline.

    Code Block
    language bash
    fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/ cd ci/pipelines/meta ./deploy_meta.sh

11. Monitor the new release pipeline and resolve any issues that may arise. 

Release Doc preparation:

...

Also write up a short paragraph on what was added to the release. This will need to go with the final announce email. Sample:

Geode 1.7.0 contains a number of improvements and bug fixes. It includes performance improvements in OQL order-by and distinct queries in client/server when security is enabled. New GFSH commands were added to get/set cluster config and to destroy gateway receivers. A new post processor was added to the new client protocol. Pulse now supports legacy SSL options. Auto-reconnecting members no more reuse old addresses and IDs. Duplicated or member-specific receivers are removed from cluster config during rolling upgrades. Users are encouraged to upgrade to the latest release.

Prepare develop branch for the next release

You will need to checkout the develop branch of geode and geode-examples.

...

1. 1. update the version property to the next release version and ensure that it has -SNAPSHOT on the end. (for example: if you created release branch for 1.8.0 update version number to 1.9.0-RELEASE on the develop branch)

...

Add the new ordinal for the new version

//Add 2 to the previous ordinal
private static final byte GEODE_1_9_0_ORDINAL = 100;

Add the new version 

public static final Version GEODE_1_9_0 =
      new Version("GEODE", "1.9.0", (byte) 1, (byte) 9, (byte) 0, (byte) 0, GEODE_1_9_0_ORDINAL);

Set the current version to the new version

public static final Version CURRENT = GEODE_1_9_0;

Update the highest version

public static final int HIGHEST_VERSION = 105;

...

Add the next version to addCommands

allCommands.put(Version.GEODE_1_9_0, geode18Commands);

...

Update the expected-pom.xml files

./gradlew clean
./gradlew build -Dskip.tests=true #note: ok if build fails expected pom test
./gradlew updateExpectedPom

Review the benchmark baseline.  In theory this could be updated to the new release branch, but the highwater tag is preferable.

See ci/pipelines/shared/jinja.variables.yml around line 19:

 benchmarks:
   baseline_branch: develop/highwater
   baseline_version: ''
   branch: develop

Publish the develop branch to origin

git add .
git commit -a -m "Upgraded version number for releasing 1.x.x"
pit push origin develop

...

Update the version and geodeVersion in gradle.properties file of the geode-example develop branch to the next release version

git checkout develop
version = 1.9.0-SNAPSHOT
geodeVersion = 1.9.0-SNAPSHOT
git add -p
git commit
git push origin HEAD

...

In Jira, add new version of develop: go to https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page and fill in the new version and click Add.

Accepting changes into the release branch:

Proposals to bring changes from develop to the support branch may be made to the dev list.  The release manager may join the conversation if needed to remind the community of the process, for example: 

Hi <thread participant(s)>, thank you for bringing your concern.

Geode's release process dictates a time-based schedule to cut release branches.  Once cut, the “critical fixes” rule allows critical fixes to be brought to the release branch by proposal on the dev list.

If there is consensus from the Geode community that your proposed change satisfies the “critical fixes” rule, I will be happy to bring it to the {version} release branch.

Regards
{Release Manager}

If three +1's are received and no minus 1's, the release manage should confirm the exact commits on develop and cherry pick to the release branch using git cherry-pick -x <SHA> then send a notification to the thread:

There appears to be consensus that this is a critical fix.

The following commit has been brought into release/{version} as the critical fix for GEODE-XXXX:

git cherry-pick -x {SHA}

GEODE-XXXX has been marked as 'resolved in' {version}.

Regards
{Release Manager}

Please note that there is no required voting period to bring a critical fix; it can be merged immediately upon getting 3 +1's.  However, the release manager should be prepared to revert it from the release branch if it causes test problems, or further discussion of the fix leads to any "minus 1"

Creating the release candidate:

From a checkout of geode, run the prepare_rc.sh script. Run this command on a machine using GUI as you will be prompted to enter PGP key password. You will see messages like "Could not find metadata org.apache.geode:geode-cq/maven-metadata.xml" on your terminal. Ignore them.

remotes/origin/release/1.9.0
cd dev-tools/release
./prepare_rc.sh -v version_with_rc -k your_8_digit_key_id

This script assumes there is a release/X.Y.Z branch pushed to all of the geode repositories (geode, geode-native, geode-examples). It will checkout the tip of that branch for all repos, build them, and copy the artifacts to the build/dist directory. It will also tag the RC in each checkout.

1. add blocks-{x.y.0} label in Jira and create a PR against support/{x.y}. After some quiet period we will prepare a release candidate and begin voting upon it. Regards {Release Manager}

   
   

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

Validate Fix Versions in JIRA

There are two parts to this audit:

1. Does every commit since the last release have a corresponding Jira ticket marked as Fixed in this version?
2. Can every Jira ticket marked as fixed in this version be traced to a commit in this support branch since the last release?

To help automate the process of identifying commits and tickets in need of review, you may find this script useful, or create your own script.

Tips:

• If a Jira ticket is fixed on develop AND cherry-picked to a support branch, it should list both fix versions.
• If a Jira ticket is fixed by way of another commit or Jira ticket, there should be a comment detailing this.
• If a Jira ticket is partially fixed but there is more work to be done in the next release, splitting into two tickets may be the best way to represent that.
• Don't forget about geode-native.  It's a separate git repository but uses GEODE Jira tickets and is released as part of Geode.
• Be mindful of revert commits.
• Be mindful of Jira tickets resolved as "Won't Fix", "Duplicate" etc.
• Be mindful of Jira tickets that were re-opened, but the Fixed version was never cleared.
• For changes that came in close to the time a support branch was cut, double-check whether the fix actually made it onto the branch.  The list of release start dates can be helpful, but checkout the release tag to confirm for certain. 
• When in doubt, reach out to people that have been involved the with ticket to confirm its status.  Many times they just forgot to marked it fixed when their PR got merged, or forgot to fill in the fixed version.

Begin preparing release documentation

1. Start preparing the release docs at Release Notes. Ask the community for suggestions on fixes and features to highlight, or go through the commits yourself and choose 5-10 items of interest. 

2. Also write up a short paragraph on what was added to the release. This will need to go with the final announce email. Sample:

   
   

   No Format

   Geode 1.13.0 contains a number of improvements and bug fixes. Changes since last release: - Performance improvements in OQL order-by and distinct queries in client/server when security is enabled. - New GFSH commands were added to get/set cluster config and to destroy gateway receivers. - A new post processor was added to the new client protocol. - Pulse now supports legacy SSL options. - Auto-reconnecting members no longer reuse old addresses and IDs. - Duplicated or member-specific receivers are removed from cluster config during rolling upgrades. Users are encouraged to upgrade to the latest release.

   
   

Creating a Release Candidate

Accept critical fixes to the support branch

It is expected that some stabilization work may be needed once the support branch is cut.  This phase may be very short or very long until a Release Candidate is proposed.

The Release Manager will set the rules for backporting changes to the support branch.  For example, they may stipulate critical fixes only and/or require a dev list proposal and/or require a PR against the support branch and/or require a label to be added in Jira. In all cases, fixes need to be made on develop first, then backported.

By some method, determine when all fixes are in.  This might involve one or more of:

• checking for Jira tickets tagged as blockers that are not yet delivered
• checking for PRs that are not yet merged
• checking on the dev list for proposals
• waiting for any test failures or other concerns to be resolved
• waiting for some quiet period of no new blocker, PRs, proposals, or concerns.

When all signs point to "go", you can either just create the RC and propose it in one email, or if there is any uncertainly, start a dev list discussion first. 

Create the release candidate

1. From one directory above a checkout of latest geode develop, run the prepare_rc script (a release-n.n.n-workspace dir will be created in the current directory).  This script will do a fresh checkout of the support branch for all repos, build them, and prepare the artifacts. It will also prepare RC tags in each repository and finally pre-stage to nexus.  Do not run this in a remote shell or headless environment, as a GUI is required to prompt for your GPG passphrase (several times) and your ASF LDAP password (Apache password). Do not include @apache.org in your apache username.  If your are not a PMC member, when prompted for SVN password, hit enter and ask a PMC member to enter their username and password, otherwise you will not be able to make the final release later.

   Code Block
   geode/dev-tools/release/prepare_rc.sh -v 1.13.0.RC1 -k last_8_digits_of_your_gpg_key -a your_apache_ldap_username

   
   

2. The "next steps" printed out at the end of the prepare_rc script will walk you through the remaining steps to finalize nexus staging (pictured below), publish the release candidate, and send the VOTE email.

3. Image Added

If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and click on "Drop"

Image Added

Sanity Checks

1. As instructed by commit_rc, before giving the RC to the community to validate, make an rc pipeline to validate that the artifacts are viable (do this in a separate terminal window as it can be quite verbose):

geode/dev-tools/release/deploy_rc_pipeline.sh -v 1.13

2. wait for all jobs to turn green (about 1-2 hours)

Send out an email announcing the RC

The last instruction from the prepare_rc script will be to run the commit_rc script.  When that is complete, it will print out the contents of the email for you to send (and also copy it to your clipboard, if you have pbcopy installed).  If you need to re-generate the email for any reason, use geode/dev-tools/release/print_rc_email.sh.  

Click on every link to validate (especially release notes!), then send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>.RC<n>".

The voting deadline should be at least 72 hours in the future (typically 3pm 5 days hence if there is a weekend).  For emergency patch releases, an expedited voting deadline of as little as 24 hours may be used.

Tally the votes

After the deadline has passed, reply to the VOTE thread with a voting result summary similar to the following (use the PMC roster to determine which votes are binding):

It's past the announced deadline and we have enough votes to close the vote.

Voting status
==========
+1: 3 binding votes
* Name (PMC member)
* Name (PMC member)
* Name (PMC member)
* Other Name
* Other Name

+0: zero votes

-0: zero votes

-1: zero votes

The voting meets the requirements of at least 3 PMC members with +1 votes and has the required majority of +1 votes.
Apache Geode {ver}.RC{n} has passed the vote and we will finalize the release shortly.

Thanks everyone for the great work!

-{Release Manager}

If not enough votes are received, the release manager may, at their discretion, extend the voting deadline, or abandon the release.

If the voting is successful, proceed to the next section.  If showstopper issues were raised, create a new release candidate.  If the release is to be abandoned, destroy any staged artifacts in nexus and svn.

Finalizing (shipping) the Release

Promote the release candidate to official release

Once a release candidate has been approved:

1. Click 'Release' in http://repository.apache.org/ (pictured below step 7)
2. Make sure you have forked https://github.com/Homebrew/homebrew-core (click the Fork button in top-right corner)
3. Make sure you have forked https://github.com/apache/geode-native
4. Make sure you have forked https://github.com/apache/geode
5. Make sure you can run dockerinfo and dockerimages.  On Linux, you may need to add sudo before each docker command in the promote_rc script and/or sudo usermod -aG docker $USER

6. From the same directory you ran the previous release scripts, run the promote_rc script (note: you must be a Geode PMC member to svn commit to dist/release/geode):

   Code Block
   geode/dev-tools/release/promote_rc.sh -v 1.13.0.RC1 -k last_8_digits_of_your_gpg_key -g your_github_username

   
   

7. The "next steps" printed at the end of the promote_rc script will walk you through the remaining tasks to validate the docker image, update Jira, make the brew PR, then finalize the release, followed by the contents of the announce email (also copied to your clipboard, if you have pbcopy installed).  You can also (re)generate the email later using geode/dev-tools/release/print_announce_email.sh.  It's ok to start on the steps below while you are waiting for promote_rc to finish.
   
   Image Added

Mark the version as released in Jira

1. Go

...

dist   - This is an svn checkout of apache's staging area. It will have artifacts added, but not committed. Review the added artifacts. You should see something like this:

dist> svn status
A       dev/geode/1.9.0.RC5
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz.asc
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz.sha256
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz.asc
A       dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz.sha256
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz.asc
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz.sha256
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip.asc
A       dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip.sha256
A       dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz
A       dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz.asc
A       dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz.sha512

If everything looks good, publish the artifacts to the nexus staging repositories. You will be prompted to enter your ASF LDAP password (Apache password)

cd build/geode
./gradlew  publish -Paskpass -Psigning.keyId=last_8_characters_of_your_gpg_fingerprint -Psigning.secretKeyRingFile=${HOME}/.gnupg/secring.gpg -PmavenUsername=your_apache_ldap_username

...

Publish release artifacts to ASF dist repo. The prepare_rc.sh script should have already added artifacts in dist/dev/geode/full_version_with_rc.

cd ../dist/dev/geode
svn commit -m "Releasing Apache Geode {version}.RC# distribution"

Update gradle.properties in geode-examples to use the RC.  Replace "1054" with the correct nexus staging ID and "1.9.0.RC4" with {version}.RC#

cd ../../../geode-examples
sed -e 's#^geodeRepositoryUrl *=.*#geodeRepositoryUrl = https://repository.apache.org/content/repositories/orgapachegeode-1054#' \
    -e 's#^geodeReleaseUrl *=.*#geodeReleaseUrl = https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1#' -i.bak gradle.properties
git add gradle.properties
git commit -m "temporarily point to staging repo for CI purposes"

Push the release tags (and the post-tag commit to geode-examples). These were already created (but not pushed) by the prepare_rc.sh script and the previous step. Be careful as `rel/` folder is protected, once we push the release tag to server, it cannot be modified. Any other change will have to be moved to the next RC number.

cd ../geode
git push origin rel/v[version_with_rc]
cd ../geode-examples
git push origin rel/v[version_with_rc] HEAD
cd ../geode-native
git push origin rel/v[version_with_rc]

Send out an email announcing the RC

From within a geode checkout, run the dist/dev/print_rc_email.sh script to generate an email to send to the dev@geode.apache.org. The subject should be "[VOTE] Apache Geode 1.9.0 RC4"

./print_rc_email.sh -v 1.9.0.RC4 -m 1054

Finalizing the release

Once the release candidate has been approved 

cd to the release branch for apache geode and tag the commit with the final version 

git tag -s rel/v{version} -m "Apache Geode v1.0.0 release" rel/v{version}.RC{latest_rc}
git push origin rel/v{version}

...

cd to the release branch for geode-examples and tag the commit with the final version, using same commands as above

...

 cd to the release branch for geode-native and tag the commit with the final version, using same commands as above

Use svn to move the distributions from dev to release. Use the folders created in step 1 of "Creating the release candidate" section.

# in the directory created in step 1 of "Creating the release candidate" section.

cd dist
svn mv dev/geode/{version}.RC#/ release/geode/{version}
svn commit -m "Releasing Apache Geode {version} distribution"

Update the keys in dist/release.

# in the directory created in step 1 of "Creating the release candidate" section.


cp dev/geode/KEYS release/geode/KEYS
svn commit -m "Updating Apache Geode KEYS file"

...

Apache Geode JIRA resolved → closed

1. Mark the version as released in Jira: go to https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page and click
2. Click on the ... to get the Actions pop-up menu and click Release.List all the JIRAs with fix version as the release version and status as resolved.
   Image Removed
   

...

*** this is a good time to go home / take a nap / finish it tomorrow.  mirror sites can take 8-24 hours to sync, and the below docker and brew and announce steps depend on most or all mirrors being up-to-date.***

Upload the docker image to docker hub.

1. docker/Dockerfile
   1. 1. Update GEODE_GPG with your GPG fingerprint.
      2. Update GEODE_VERSION with the release version (eg. 1.8.0)
      3. Update GEODE_SHA256 with the SHA from https://dist.apache.org/repos/dist/release/geode/{VERSION}/apache-geode-{VERSION}.tgz.sha256 (Replace VERSION with the version you are trying to release).
2. Check these changes in to the release branch. If for some reason you have already merged the release branch to master and deleted it, check the changes in to master.
3. Follow the instruction present in docker/README.md
4. Note that you may see a 404 error during the docker build process, because it tries a mirror first before falling back to the primary download site, and some mirror sites take 8-24 hours to sync.  As long as the docker build completes successfully you're ok.

Update the brew formula

# update brew
brew update


# Navigate to homebrew core directory
cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula



# Create a release branch
git checkout -b apache-geode-{version}


#Open apache-geode.rb
vim apache-geode.rb


# add the correct version in lines below 
# in url update "https://www.apache.org/dyn/closer.cgi?path=geode/{version}/apache-geode-{version}.tgz"
# in sha256 update with the SHA256 from https://dist.apache.org/repos/dist/release/geode/{version}/apache-geode-{version}.tgz.sha256


# save the file 


#commit the file - put the right version in below command.
git add .
git commit -a -m "apache-geode {version}"


# Fork git@github.com:Homebrew/homebrew-core.git to your repositories.
#add the remote 
git remote add myfork {your forked homebrew core repo}


#push to your remote forked repo
git push myfork apache-geode-{version}


#create a PR against git@github.com:Homebrew/homebrew-core.git - monitor the the tests in the PR page


#test it locally.
git checkout master


git merge apache-geode-{version}
brew install --build-from-source apache-geode


#check for gfsh version - should be the released version
gfsh version


# uninstall apache-geode
brew uninstall apache-geode


#reset master to origin
git reset --hard origin/master

...

1. for the version you are releasing
2. Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
3. While you're in there, add the next patch release (i.e. if you are releasing x . y . n, add x . y . n+1) 

Transition JIRA issues fixed in this release from Resolved → Closed

1. List all the JIRAs with fix version as the release version and status as resolved.
   Image Added
   
   
   
2. Using bulk operations → transition to closed state.
   
   
   Image Added
   
   Image Added
   
   Image Added
   
   Image Added
   
   

Publish to GitHub

1. Go to https://github.com/apache/geode/tags 

2. Locate (but do not click on) the row with the final release tag (e.g. rel/v1.13.0)

3. Click on the 2nd "..." menu (the one to the right of the Verified bubble), then Create release.

4. "Existing tag" should be selected.
5. Fill in Release Title e.g. Apache Geode 1.13.0.

6. Describe the release:

   1. Copy the summary sentence from the release notes.

   2. Add the SHA256 (e.g. from the directory you ran the release scripts, cat release-1.13.0-workspace/geode/geode-assembly/build/distributions/apache-geode-1.13.0.tgz.sha256).

   3. Add a link to the release notes.  Example: 

      Code Block
      title Sample Release Description
      This release contains some new gfsh commands and support for SNI as well as a number of improvements and bug fixes. sha256 for apache-geode-1.13.0.tgz is 8caf6dcafa5c6bb7c10dc7d512d0569dd16e463e01c18997118e20a5f43e6097 See full release notes at https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.0

      
      

7. Click where it says "Attach binaries" and upload the Apache Geode .tgz (found in the directory you ran the release scripts under release-1.13.0-workspace/geode/geode-assembly/build/distributions/apache-geode-1.13.0.tgz)
8. Click the green Publish Release button. 

Publish javadocs and documentation to the website

Ask on the dev list if you need help with these steps.

1. Keep only the latest patch release of each of the 3 most recent minors (including the one you're about to release) on https://geode.apache.org/releases/

2. Build website from sources as described in geode-site/website/README.md.
3. In the generated site, create the directory geode-site/content/releases/latest.
4. Obtain a copy of the javadoc directory from the binary release and put it in the geode-site/content/releases/latest directory (link from the website's Docs landing page points to ../releases/latest/javadoc).
5. Deploy the generated site by checking it into the asf-site branch of the apache-geode repo.

Final checks

(note: These steps are also covered by the "Final steps" printed at the end of promote_rc)

1. Confirm that your brew PR has been merged or closed and brew install apache-geode picks up the new release.  Note: this may take overnight...no need to hold the release announcement just for brew.

   Code Block
   brew uninstall apache-geode brew install apache-geode gfsh version

   
   

2. Check that docs for the version you are releasing appear on https://geode.apache.org/docs/
3. Check that download detail for the version you are releasing appear on https://geode.apache.org/releases/
4. Check that the release tag appears as "Verified" in https://github.com/apache/geode/tags (if not, see last step in Permissions and Keys)

Ask for a volunteer to update dependencies on develop (major/minor only)

Now is the best time to bump dependency versions on develop for the various 3rd-party libraries used by Geode. Start a DISCUSS thread asking for a volunteer to lead this effort.

To:  dev@geode.apache.org

Subject: [DISCUSS] Volunteer to update 3rd-party libraries used by GEODE

Hello Apache Geode Community, 

It's time to update the 3rd-party libraries used by GEODE.  We need a volunteer to take on this responsibility.

https://github.com/apache/geode/blob/develop/dev-tools/dependencies/README.md describes how to carry out this task.

It would be awesome to get this done within the next few weeks, to allow plenty of time to shake out any issues before the next release.

Regards,
{Release Manager} on behalf of the Apache Geode team

Remove old unsupported branches (major/minor only)

Geode's N-2 support policy allows patch releases to be proposed for its 3 most recent minors, e.g. on the day 1.15.0 is released, 1.12 would become no longer supported.  But this is not set in stone, so it's probably wise to start a discussion on the dev list before just running this command!

1. remove 1.<N-3> support branch, pipelines and RC tags:

geode/dev-tools/release/end_of_support.sh -v 1.{N-3}

Note tha end_of_support is a destructive command.  It will prompt you to continue, then will delete the branch and pipeline.  If run by accident, these can be restored by re-flying the pipeline and re-pushing the branch (if you or someone has an up-to-date local copy, otherwise google git reflog for more ways to recover a deleted branch).

Send the announce mail

The template for this email was output at the end of promote_rc, or you can re-generate it using geode/dev-tools/release/print_announce_email.sh.  Consider customizing the generated text if there are more upcoming releases (or even waiting and combining the announcements) or if there are notable fixes worth highlighting after the generic "contains a number of fixes".

Publish javadocs and documentation to the website

...

Destroy concourse release pipelines

fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/
cd ci/pipelines/meta
./destroy_pipelines.sh

Merge to master and destroy release branch

Merge release branch to master for apache geode and then delete the release branch

git fetch --all
git checkout release/1.9.0
git merge -s ours origin/master -m "Merging release/1.9.0 into master"
git checkout master
git merge release/1.9.0
git push origin master
  
git branch -D release/{version}
git push origin --delete release/{version}

...

Merge release branch to master for geode-examples and then delete the release branch, using same commands as above

...

Add released version as "old" on develop

Check out develop and add the released version and update the benchmark baseline.

Eg. in settings.gradle somewhere around line 75:

'1.9.0'].each

and in ci/pipelines/shared/jinja.variables.yml around line 59:

set baseline_branch: ""
set baseline_version: "1.9.0"

It's a good idea to make a PR for this rather than committing directly, since these changes affect tests!

Sending the announce mail.

To:  user@geode.apache.org, announce@apache.org, dev@geode.apache.org

Subject: [ANNOUNCE] Apache Geode 1.9.0

*** Important: Send the email from your apache email ID*** (otherwise announce@apache.org will bounce. See https://referenceinfra.apache.org/committer/-email.html for how to send email from your apache email address)

The Apache Geode community is pleased to announce the availability of
Apache Geode {version}.
Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.
Geode {version} contains a number of improvements and bug fixes. It includes performance improvements in OQL order-by and distinct queries in client/server when security is enabled. New GFSH commands were added to get/set cluster config and to destroy gateway receivers. A new post processor was added to the new client protocol. Pulse now supports legacy SSL options. Auto-reconnecting members no more reuse old addresses and IDs. Duplicated or member-specific receivers are removed from cluster config during rolling upgrades. Users are encouraged to upgrade to the latest release.
For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/
Release+Notes#ReleaseNotes-{version}
The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/
The release documentation is available at:
http://geode.apache.org/docs/guide/{version eg. in the format as 17 or 18 or 19}/about_geode.html
We would like to thank all the contributors that made the release possible.
Regards,
{Release Manager} on behalf of the Apache Geode team

Remove previous release from mirrors.

remove from apache mirrors

cd dist/release/geode
svn rm {$old_release}
svn commit -m "remove old releases (they can still be found at http://archive.apache.org/dist/geode)"

*** Important: Send the email as plain text***(otherwise announce@apache.org will reject the email.  If using gmail, at the bottom of the compose window, click the three-dot menu then click Plain text mode)

Example:

To:  user@geode.apache.org, announce@apache.org, dev@geode.apache.org

Subject: [ANNOUNCE] Apache Geode {version e.g. 1.13.0}

The Apache Geode community is pleased to announce the availability of
Apache Geode {version e.g. 1.13.0}.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode {version e.g. 1.13.0} contains a number of improvements and bug fixes. It includes performance improvements in OQL order-by and distinct queries in client/server when security is enabled. New GFSH commands were added to get/set cluster config and to destroy gateway receivers. A new post processor was added to the new client protocol. Pulse now supports legacy SSL options. Auto-reconnecting members no more reuse old addresses and IDs. Duplicated or member-specific receivers are removed from cluster config during rolling upgrades. Users are encouraged to upgrade to the latest release.
For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-{version e.g. 1.13.0}

The release artifacts can be downloaded from the project website:
https://geode.apache.org/releases/

The release documentation is available at:
https://geode.apache.org/docs/guide/{version eg. 113}/about_geode.html

We would like to thank all the contributors that made the release possible.
Regards,
{Release Manager} on behalf of the Apache Geode team

...

1. before: http://apache.org/dyn/closer.cgi/geode...
2. after: http://archive.apache.org/dist/geode...

...