+1 I definitely like the idea of scheduled releases. I wonder if cutting the release branch a month ahead of time is overkill, but I guess we do seem to keep finding issues after the branch is cut.
-Dan On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <amurm...@pivotal.io> wrote: > Hi everyone, > > I want to propose shipping Geode on a regular cadence. My concrete proposal > is to ship Geode every 3 months on the first weekday. To make sure we hit > that date we would cut the release 1 months prior to that day. > > *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. 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. > > Some other successful Apache projects share similar approaches: > > - Kafka > <https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan> > releases every 4 months and cuts the release 1 month prior > - PredictionIO <https://predictionio.apache.org/resources/release/> > releases > every 2 months > - Spark <https://spark.apache.org/versioning-policy.html> does not seem > to have a hard date, but aims to ship every 6 months, so there is at > least > a goal date > > > *What?* > As stated above, I suggest to release every three months. Given we just > shipped the next release would go out on January 2nd. That timing in > unfortunate, due to the holidays. Therefore I propose to aim for a December > 3rd (1st Monday in December) release. In order to meet that date, we should > cut the release branch on November 1st. That also means that we should > start finding a volunteer to manager the release on October 25th. I know > this seems really close, given we just shipped, but keep in mind that this > is to avoid the holidays and that we already have close to a month worth of > work on develop. > > *Proposed near future schedule:* > October 25th: Find release manager > November 1st: Cut 1.8 release branch > December 1st: Ship 1.8 > January 28th: Find release manager > February 1st: Cut 1.9 release branch > March 1st: Ship 1.9 > and so on... > > Thanks for sharing your thoughts and feedback on this! >
