...

...

Terminology

A minor major release is a version x.y0.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 > 0 and should contain a limited number of critical fixes only.

Except where noted, all instructions in this guide apply to both all three types of releases.

Announce intent to branch (minor only)

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

Note: patch release(s) are initiated by dev list proposal only (not on any time-based schedule), 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.

Branching for release

Create the support branches (minor only)

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.

   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. If any changes are needed please add blocks-{x.y.0} label in Jira and create a PR against support/{x.y}.

   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

   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'

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

...

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

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

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).  The support branch should already exist at this point.  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 get a PMC member to enter their username and password, otherwise you will not be able to make the final release later.

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

.  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

...

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.

...

Image Removed

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 Removed

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:

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.  

Be sure to click on EVERY link to validate, then send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>.RC<n>".  

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):

...

If not enough votes are received, the release manager may, at their discretion, extend the voting deadline, or close the vote and start a DISCUSS thread on whether to abandon the release or try again.

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

...

1. Click 'Release' in http://repository.apache.org/ (pictured below step 57)
2. Fork 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 can run docker info and docker images.  On Linux, be sure to add the your user to the docker group to avoid requiring 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 'your_40_digitlast_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.
   
   

Mark the version as released in Jira

1. Go to https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
2.  Click Click on the ... to get the Actions pop-up menu for the version you are releasing
3. Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
4. While youWhile you're in there, add the next patch release (i.e. if you are releasing x . y . n, add x . y . n+1) Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).

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.
   
   
   
   
2. Using bulk operations → transition to closed state.
   
   
   
   
   
   
   
   
   
   
   

Publish

...

to

...

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.

Wait for mirror sites to sync

*** this is a good time to call it a day...mirrors take overnight to sync the new release, and sometimes days for mavencentral ***

Don't forget to finish the remaining "Next steps" from promote_rc in the morning.

Final checks

(note: These steps are also covered by the "Next steps" from promote_rc)

Confirm that your brew PR has been merged or closed and brew install apache-geode picks up the new release.  

brew install apache-geode
gfsh version

...

1. Check for the version you are releasing to appear on https://mvnrepository.com/artifact/org.apache.geode/geode-core
2. Plus the Examples pipeline for your support branch (e.g. at https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-examples)

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

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

*** 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:

Ask for a volunteer to update dependencies

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

To:  dev@geode.apache.org

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

Hello Apache Geode Community, 

It is time to update the 3rd-party libraries used by GEODE. To get that done, I am requesting a volunteer to take on the responsibility.

This consists of going through the libraries we depend on and updating them to the latest version that works with our code.

It would be nice to get this done within the next week or two, so that we have time to shake out issues before the next release.

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

...

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

Subject: [ANNOUNCE] Apache Geode 1.13.0*** Important: Send the email from your apache email ID*** (otherwise announce@apache.org will bounce. See https://reference.apache.org/committer/email for how to send email from your apache email address)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:
httphttps://geode.apache.org/releases/

The release documentation is available at:
httphttps://geode.apache.org/docs/guide/{version eg. in the format as 17 or 18 or 19113}/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

...