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!