+1 on the scheduled release and also on one month prior to release we cut the branch.
@Dan I feel keeping a one month will give a very comfortable time frame to test + retest the release branch and we will be releasing a stable release candidate. For 1.7.0, it did take a month from cutting the branch till releasing RC2. As testing of release/1.7.0 + RC1 was time bounded as voting time frame was 72hours. If we have the release branch for a month, we don't have to hurry with the testing. Regards Nabarun Nag On Thu, Oct 4, 2018 at 2:43 PM Dan Smith <dsm...@pivotal.io> wrote: > +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! > > >
