+1 on cutting in Nov. Seems like community could benefit from one more release this year.
-- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Oct 5, 2018 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! > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
