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! >>>>>>> >>>>>> >>>>> >>>> >>> >>
