+1 to a regular cadence and starting with a 3-month cadence. As we learned earlier this year, monthly was too frequent to support our testing cycles and for users to update.
On Fri, Oct 5, 2018 at 11:54 AM, Robert Houghton <rhough...@pivotal.io> wrote: > +1 to Dan > > On Fri, Oct 5, 2018, 09:27 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! > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
