> Is it rooted more on hitting those in the short term? Yes. And a better test infra could make it feasible. Or it may be easier to hit by limiting the minor version to bug fix and docs update.
On Tue, Sep 8, 2020 at 10:41 PM Pratyaksh Sharma <[email protected]> wrote: > Missed this thread, the plan looks good to me as well. > > On Wed, Sep 9, 2020 at 8:31 AM Vinoth Chandar <[email protected]> wrote: > > > Would love to understand the general skepticism a bit more. > > Is it rooted more on hitting those in the short term? or even in the > longer > > run with a better test infrastructure in place? > > > > On Tue, Sep 8, 2020 at 6:42 PM Raymond Xu <[email protected]> > > wrote: > > > > > +1. Also a bit skeptical on monthly minor releases. But can give it a > > try. > > > > > > On Tue, Sep 8, 2020 at 5:55 PM Mehrotra, Udit > <[email protected] > > > > > > wrote: > > > > > > > +1 on the process. > > > > > > > > On 9/8/20, 5:11 PM, "Vinoth Chandar" <[email protected]> wrote: > > > > > > > > CAUTION: This email originated from outside of the organization. > Do > > > > not click links or open attachments unless you can confirm the sender > > and > > > > know the content is safe. > > > > > > > > > > > > > > > > >, bit skeptical on minor version releases every month, but nvm. > > > guess > > > > its > > > > just a rough estimate. > > > > > > > > That's an aspirational goal that we should try to hit. We have > all > > > > worked > > > > on teams/projects that shipped at that cadence regularly. > > > > It's a matter of getting our test infrastructure and processes > > > > streamlined > > > > IMO :) > > > > > > > > On Fri, Sep 4, 2020 at 8:29 AM Nishith <[email protected]> > > wrote: > > > > > > > > > +1 on the process > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > On Sep 3, 2020, at 8:14 AM, Sivabalan <[email protected]> > > > wrote: > > > > > > > > > > > > +1 on the general release policy. Realistically speaking, bit > > > > skeptical > > > > > on > > > > > > minor version releases every month, but nvm. guess its just a > > > rough > > > > > > estimate. > > > > > > > > > > > >> On Tue, Sep 1, 2020 at 8:41 PM Balaji Varadarajan > > > > > >> <[email protected]> wrote: > > > > > >> > > > > > >> > > > > > >> +1 on the process. > > > > > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, > > Gary > > > > Li < > > > > > >> [email protected]> wrote: > > > > > >> > > > > > >> +1 > > > > > >> Gary LiFrom: Bhavani Sudha <[email protected]> > > > > > >> Sent: Wednesday, September 2, 2020 3:11:06 AM > > > > > >> To: [email protected] <[email protected]> > > > > > >> Cc: [email protected] <[email protected]> > > > > > >> Subject: Re: [DISCUSS] Formalizing the release process +1 on > > the > > > > release > > > > > >> process formalization. > > > > > >> > > > > > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar < > > > > [email protected]> > > > > > wrote: > > > > > >>> > > > > > >>> Hi all, > > > > > >>> > > > > > >>> Love to start a discussion around how we can formalize the > > > > release > > > > > >>> process, timelines more so that we can ensure timely and > > > quality > > > > > >> releases. > > > > > >>> > > > > > >>> Below is an outline of an idea that was discussed in the > last > > > > community > > > > > >>> sync (also in the weekly sync notes). > > > > > >>> > > > > > >>> - We will do a "feature driven" major version release, > every > > 3 > > > > months > > > > > or > > > > > >>> so. i.e going from version x.y to x.y+1. The idea here is > > this > > > > ships > > > > > once > > > > > >>> all the committed features are code complete, tested and > > > > verified. > > > > > >>> - We keep doing patches, bug fixes and usability > improvements > > > to > > > > the > > > > > >>> project always. So, we will also do a "time driven" minor > > > version > > > > > release > > > > > >>> x.y.z → x.y.z+1 every month or so > > > > > >>> - We will always be releasing from master and thus major > > > release > > > > > features > > > > > >>> need to be guarded by flags, on minor versions. > > > > > >>> - We will try to avoid patch releases. i.e cherry-picking a > > few > > > > commits > > > > > >>> onto an earlier release version. (during 0.5.3 we actually > > > found > > > > the > > > > > >>> cherry-picking of master onto 0.5.2 pretty tricky and even > > > > > error-prone). > > > > > >>> Some cases, we may have to just make patch releases. But > only > > > > > extenuating > > > > > >>> circumstances. Over time, with better tooling and a larger > > > > community, > > > > > we > > > > > >>> might be able to do this. > > > > > >>> > > > > > >>> As for the major release planning process. > > > > > >>> > > > > > >>> - PMC/Committers can come up with an initial list sourced > > > > based on > > > > > >>> user asks, support issue > > > > > >>> - List is shared with the community, for feedback. > > community > > > > can > > > > > >>> suggest new items, re-prioritizations > > > > > >>> - Contributors are welcome to commit more features/asks, > > > (with > > > > due > > > > > >>> process) > > > > > >>> > > > > > >>> I would love to hear +1s, -1s and also any new, completely > > > > different > > > > > >> ideas > > > > > >>> as well. Let's use this thread to align ourselves. > > > > > >>> > > > > > >>> Once we align ourselves, there are some release > certification > > > > tools > > > > > that > > > > > >>> need to be built out. Hopefully, we can do this together. > :) > > > > > >>> > > > > > >>> > > > > > >>> Thanks > > > > > >>> Vinoth > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > -Sivabalan > > > > > > > > > > > > > > > > > > >
