Versions Compared

Key

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

Geode releases are driven by the community.  A release should first be proposed on the dev list, then a PMC member must volunteer as Release Manager.  See Backporting Tips if you'd like to include a major/critical fix in a release after the support branch has been cut.

Upcoming Releases

None, unless someone volunteers for one or more of the following:

Apache Geode 1.16.0

Release Manager: 

Branch: develop

Label: blocks-1.16.0

Status: passive (accepting contributions, but a Release Manager has not yet volunteered)

Apache Geode 1.15.1

Release Manager: 

Branch: support/1.15

Label: blocks-1.15.1

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

Apache Geode 1.14.5

Release Manager: 

Branch: support/1.14

Label: blocks-1.14.5

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

Apache Geode 1.13.9

Release Manager: 

Branch: support/1.13

Label: blocks-1.13.9

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

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!