Geode aims for at least one minor release a year, and usually a few patch releases in between.  After a release is proposed on the dev list and a Release Manager has volunteered, shipping typically takes a month or more.  If you'd like to include a major/critical fix in a release after the support branch has been cut, see Backporting Tips

Upcoming Releases

Plans may change, but here's what might be

Apache Geode 1.15.0

Release Manager: Owen Nichols

Branch: support/1.15

Status: active (not yet released)

Jira

Apache Geode 1.14.4

Release Manager: 

Branch: support/1.14

Status: passive (backporting allowed, but a Release Manager has not yet volunteered)

Jira

Apache Geode 1.13.8

Release Manager: 

Branch: support/1.13

Status: approaching end-of-life (backporting allowed, but another release appears unlikely)

Jira

Apache Geode 1.12.9

Release Manager: 

Branch: support/1.12

Status: approaching end-of-life (backporting allowed.  Once 1.15.0 ships, the project must decide whether to drop support for 1.12 or 1.13 to satisfy Geode's N-2 support policy)

Jira

Past Releases

See https://geode.apache.org/releases

As stated above, we release a new minor release every three months. The release branch will be cut a month before the target ship date. Since the branch gets cut by a release manager, search for a release manager gets started a week before the cut date. 

Why?

Knowing on what day the release will get cut and on what day we ship allows community members to plan their contributions. If I want my feature to be in the next release I know by when I need to have it merged to develop and can plan accordingly and cut scope if required. As a user who is waiting for a particular feature or fix that's already on develop, I know when to expect the release that includes this work and again, can plan accordingly.

This makes working and using Apache Geode more predictable which makes all our lives less stressful. To make this work, it's important to be strict about cutting the release branch on the set date and only allow critical fixes after the release has been cut. Once we start compromising on this, we go down a slippery slope that ultimately leads to not getting the predictability benefits described here.

Upcoming Releases

Apache Geode 1.8

October 25th: Find release manager 
November 1st: Cut release branch 
December 1st: Ship it! 

Apache Geode 1.9

January 28th: Find release manager 
February 1st: Cut release branch 
March 1st: Ship it!