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