...

1. git →  https://git-scm.com/downloads
2. docker → https://docs.docker.com/docker-for-mac/install/ 
3. svn → [on Mac, install command line tools → https://stackoverflow.com/questions/9329243/xcode-install-command-line-tools]
4. gpg tools → https://gpgtools.org
5. java JDK8 → https://adoptopenjdk.net Make sure you have the latest patch release of OpenJDK 1.8.0 (not Oracle JDK).
6. Homebrew (optional) → https://brew.sh/
7. svn → [on Mac, brew install svn]
8. 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.
9. cmake, doxygen, and openssl - install using an appropriate package manager, e.g. on Mac: brew install doxygen && brew install cmake && brew install openssl
10. jinja → sudo pip3 install Jinja2
11. PyYAML → sudo pip3 install PyYAML
12. text editor (vi or whatever you prefer)
13. web browser

...

...

Announce intent to branch (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).  About a week before, unless otherwise decided on the dev list.  A week or two before the scheduled date, send a [DISCUSS] email to dev@geode.apache.org informing developers proposing that a new support branch is about to 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.

Note: patch release(s) are made only initiated by proposal on the dev list proposal only (not on a any time-based schedule), from existing and will include any fixes already accumulated on the support branch(es) plus whatever may be specifically proposed to drive the patch release.  Patch release proposals must be made within nine months of the initial minor release.  

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.

...

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 the more recent of  {previous release} or develop/highwater.  Note: as the release progresses, consider creating and using a dedicated version/highwater tag on the support branch.

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

   Code Block
   language yml
   benchmarks: baseline_branch: develop/highwater baseline_version: '' benchmark_branch: support/{x.y}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}" We hope to make a final release in about a month. 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 (Bump the version of the develop branch (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).

   Review the benchmark baseline on develop.  Ask on the dev list if you are unsure whether the last support branch or a highwater tag makes the most sense.

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

   Code Block
   benchmarks: baseline_branch: develop/highwater baseline_version: '' benchmark_branch: develop

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:

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
• 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

...

• 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.

Proposals to bring completed and tested fixes from develop to the support branch may be made to the dev list.  The release manager should confirm that the ticket is in a resolved state on develop and has passed automated testing on develop.

Once three +1's are received (and no "minus 1"), the release manager may give the go-ahead for whoever proposed the fix to bring it to the support branch (via a PR or a cherry-pick -x).

After the fix has been merged, make sure the issue is marked with the correct fixed-in version(s) in Jira (every branch the commit is brought to should be listed).

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

Proposals to bring completed and tested fixes 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 (omit the time-based part if this is a patch release): 

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

Geode's release process dictates a time-based schedule to cut support branches.  Once cut, the “critical fixes” rule allows critical fixes to be brought to the support 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 support/{x.y} branch.

Regards
{Release Manager}

If three +1's are received and no minus 1's, the release manager should:

• confirm that the ticket is already in a resolved state on develop
• confirm the exact commits on develop
• cherry pick to the support branch
  • git cherry-pick -x {SHA} && ./gradlew build 
  • if fix does not cherry-pick and build cleanly, ask that a PR be submitted against the support branch
• send a notification to the thread and mark the issue with the correct fixed-in version in Jira:

...

No minimum voting period is required to bring a critical fix; it can be merged immediately upon getting

...

three +1's.  However, the release manager should monitor and be prepared to revert it from the support branch if it causes test problems, or further discussion of the fix leads to any "minus 1".

Create the release candidate

...

1. Click 'Release' in http://repository.apache.org/ (pictured below step 5)
2. Fork https://github.com/Homebrew/homebrew-core
3. Make sure you can run docker info and docker images.  On Linux, this may require sudo (edit the promote_rc script to prefix all docker commands with sudobe sure to add the your user to the docker group to avoid requiring sudo (sudo usermod -aG docker $USER).

4. 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 'your_40_digit_gpg_key' -g your_github_username

   
   

5. 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.
   
   

...