+1 to releasing on a 3-month schedule and cutting the branch a month before the release.
I’ve always felt that releasing based on content tends to prolong the test/release cycle. Some features are held up from getting released due to waiting for other features to be completed. Releasing on a relatively short fixed cadence means that new work “gets out there” quicker. Even if a new feature doesn’t yet have all the bells and whistles implemented, the project can get feedback sooner on the usability of what is there. > On Oct 5, 2018, at 9:27 AM, Dan Smith <dsm...@pivotal.io> wrote: > > Ok, I buy your arguments to cut the release branch 1 month ahead of time. > I'm fine with that plan, as long as we can stick to only putting critical > fixes on the release branch. Once the release branch is cut, it ships > without further changes unless we find new issues. > > -Dan > > > On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann <amurm...@pivotal.io> > wrote: > >> Robert and Sai, I think either release process can be stressful if your >> team doesn't understand that there is no faster button, but that the only >> lever is to cut scope (you can also compromise quality, but let's not do >> that). >> In either scenario there can be release pressure. To me the biggest >> difference is that with a fixed schedule I at least have a good chance to >> see sooner that I need to cut scope to catch the next train. Without a >> fixed schedule, I suddenly might find myself in the situation that everyone >> else is ready to ship and is waiting on me and getting impatient. I might >> have not even been able to see that coming unless I am constantly checking >> with everyone else to find out when they think they might be ready to ship. >> >> To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a >> massively growing community 😉 >> >> On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker <aba...@pivotal.io> wrote: >> >>> I’ve been advocating for a fixed release schedule for a long time. 3 >>> months seems like a good rate given the release overhead. >>> >>> +1 on cutting the next release branch in November and shooting for an >>> early December v1.8.0 release. >>> >>> Anthony >>> >>> >>>> On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <sai.boorlaga...@gmail.com >>> >>> wrote: >>>> >>>> I agree with Robert that we should release based on features that go >> in. >>>> >>>> I am not sure if Apache Kafka & Spark are a good reference for GEODE. >>>> These tools were evolving rapidly in the last couple of years and >>> frequent >>>> releases would be good for a growing community. >>>> >>>> Should we do a patch release every few months to include bug fixes? >>>> >>>> Sai >>>> >>>> >>>> On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton <rhough...@pivotal.io> >>> wrote: >>>> >>>>> I have found it refreshing that the geode released cadence has been >>> based >>>>> on features being done, rather than a set schedule. >>>>> >>>>> I come from an environment where we had quarterly releases and monthly >>>>> patches to all supported previous releases, and I can tell you that it >>>>> became a grind. That being said, within that release cadence a >> one-month >>>>> ramp for bug fixes on the release branch was almost always sufficient. >>>>> >>>>> On Thu, Oct 4, 2018, 18:32 Ryan McMahon <mcmellaw...@apache.org> >> wrote: >>>>> >>>>>> +1 for scheduled releases and cutting the branch one month prior to >>>>>> release. Given the time it took to fully root out, classify, and >> solve >>>>>> issues with this 1.7 release, I think a month is the right amount of >>> time >>>>>> between cutting the branch and releasing. If it ends up being too >> much >>>>> or >>>>>> too little, we can always adjust. >>>>>> >>>>>> I don’t feel strongly about the release cadence, but I generally >> favor >>>>> more >>>>>> frequent releases if possible (3 month over 6 month). That way new >>>>>> features can get into the hands of users sooner, assuming the feature >>>>> takes >>>>>> less than 3 months to complete. Again, we can adjust the cadence if >>>>>> necessary if it is too frequent or infrequent. >>>>>> >>>>>> Ryan >>>>>> >>>>>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann < >> amurm...@pivotal.io> >>>>>> wrote: >>>>>> >>>>>>> Anil, releasing every 3 months should give us 3 months of dev work. >>>>> Don't >>>>>>> forget that there will be one month during which the next release is >>>>>>> already cut, but the vast majority of the work is going to the >> release >>>>>>> after that. So while we cut 1.7 one month ago and release 1.7 today, >>> we >>>>>>> already have one month of work on develop again. It's not going to >>> work >>>>>> out >>>>>>> for this first release though, due to my suggestion to cut a month >>>>> early >>>>>> to >>>>>>> avoid holidays. If I recall correctly our past problem was that it >>> took >>>>>>> longer to iron out issue on the release branch than expected. The >>>>>> solution >>>>>>> to that would be to cut the release even earlier, but 1 month feels >>>>> very >>>>>>> generous. >>>>>>> >>>>>>> On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade < >> aging...@pivotal.io >>>> >>>>>>> wrote: >>>>>>> >>>>>>>> If I remember from earlier discussion; the plan was to deliver a >>>>>> release >>>>>>>> once 3 months. But from the past release history we had difficulty >> in >>>>>>>> achieving that, either the features are not completely ready or the >>>>>>>> bug-fixes have taken more time. We need verify what is right for >>>>> Apache >>>>>>>> Geode, 3, 4 or 6 months; and there is any community dev/activity >> that >>>>>>>> depends on Geode release. >>>>>>>> My vote will be for 4 or 6 months, as it provides at least 3+ month >>>>> for >>>>>>> dev >>>>>>>> activity and 1 month for QA. >>>>>>>> >>>>>>>> -Anil. >>>>>>>> >>>>>>>> >>>>>>>> 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! >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>
