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