You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@hudi.apache.org by Vinoth Chandar <vi...@apache.org> on 2020/09/01 17:21:40 UTC
[DISCUSS] Formalizing the release process
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
Re: [DISCUSS] Formalizing the release process
Posted by Vinoth Chandar <vi...@apache.org>.
Thanks everyone for the feedback.
This is now captured here
https://cwiki.apache.org/confluence/display/HUDI/Release+Management
On Sat, Sep 12, 2020 at 4:06 PM Raymond Xu <xu...@gmail.com>
wrote:
> > 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 <pr...@gmail.com>
>
> wrote:
>
>
>
> > Missed this thread, the plan looks good to me as well.
>
> >
>
> > On Wed, Sep 9, 2020 at 8:31 AM Vinoth Chandar <vi...@apache.org> 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 <xu.shiyan.raymond@gmail.com
> >
>
> > > 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
>
> > <uditme@amazon.com.invalid
>
> > > >
>
> > > > wrote:
>
> > > >
>
> > > > > +1 on the process.
>
> > > > >
>
> > > > > On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com>
>
> > > wrote:
>
> > > > >
>
> > > > > > +1 on the process
>
> > > > > >
>
> > > > > > Sent from my iPhone
>
> > > > > >
>
> > > > > > > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com>
>
> > > > 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
>
> > > > > > >> <v....@ymail.com.invalid> wrote:
>
> > > > > > >>
>
> > > > > > >>
>
> > > > > > >> +1 on the process.
>
> > > > > > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM
> PDT,
>
> > > Gary
>
> > > > > Li <
>
> > > > > > >> garyli1019@outlook.com> wrote:
>
> > > > > > >>
>
> > > > > > >> +1
>
> > > > > > >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
>
> > > > > > >> Sent: Wednesday, September 2, 2020 3:11:06 AM
>
> > > > > > >> To: users@hudi.apache.org <us...@hudi.apache.org>
>
> > > > > > >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
>
> > > > > > >> Subject: Re: [DISCUSS] Formalizing the release process +1
> on
>
> > > the
>
> > > > > release
>
> > > > > > >> process formalization.
>
> > > > > > >>
>
> > > > > > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <
>
> > > > > vinoth@apache.org>
>
> > > > > > 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
>
> > > > > >
>
> > > > >
>
> > > > >
>
> > > >
>
> > >
>
> >
>
>
Re: [DISCUSS] Formalizing the release process
Posted by Raymond Xu <xu...@gmail.com>.
> 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 <pr...@gmail.com>
wrote:
> Missed this thread, the plan looks good to me as well.
>
> On Wed, Sep 9, 2020 at 8:31 AM Vinoth Chandar <vi...@apache.org> 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 <xu...@gmail.com>
> > 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
> <uditme@amazon.com.invalid
> > >
> > > wrote:
> > >
> > > > +1 on the process.
> > > >
> > > > On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com>
> > wrote:
> > > >
> > > > > +1 on the process
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com>
> > > 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
> > > > > >> <v....@ymail.com.invalid> wrote:
> > > > > >>
> > > > > >>
> > > > > >> +1 on the process.
> > > > > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT,
> > Gary
> > > > Li <
> > > > > >> garyli1019@outlook.com> wrote:
> > > > > >>
> > > > > >> +1
> > > > > >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> > > > > >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> > > > > >> To: users@hudi.apache.org <us...@hudi.apache.org>
> > > > > >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> > > > > >> Subject: Re: [DISCUSS] Formalizing the release process +1 on
> > the
> > > > release
> > > > > >> process formalization.
> > > > > >>
> > > > > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <
> > > > vinoth@apache.org>
> > > > > 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
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Formalizing the release process
Posted by Pratyaksh Sharma <pr...@gmail.com>.
Missed this thread, the plan looks good to me as well.
On Wed, Sep 9, 2020 at 8:31 AM Vinoth Chandar <vi...@apache.org> 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 <xu...@gmail.com>
> 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 <uditme@amazon.com.invalid
> >
> > wrote:
> >
> > > +1 on the process.
> > >
> > > On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com>
> wrote:
> > >
> > > > +1 on the process
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com>
> > 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
> > > > >> <v....@ymail.com.invalid> wrote:
> > > > >>
> > > > >>
> > > > >> +1 on the process.
> > > > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT,
> Gary
> > > Li <
> > > > >> garyli1019@outlook.com> wrote:
> > > > >>
> > > > >> +1
> > > > >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> > > > >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> > > > >> To: users@hudi.apache.org <us...@hudi.apache.org>
> > > > >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> > > > >> Subject: Re: [DISCUSS] Formalizing the release process +1 on
> the
> > > release
> > > > >> process formalization.
> > > > >>
> > > > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <
> > > vinoth@apache.org>
> > > > 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
> > > >
> > >
> > >
> >
>
Re: [DISCUSS] Formalizing the release process
Posted by Vinoth Chandar <vi...@apache.org>.
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 <xu...@gmail.com>
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 <ud...@amazon.com.invalid>
> wrote:
>
> > +1 on the process.
> >
> > On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com> wrote:
> >
> > > +1 on the process
> > >
> > > Sent from my iPhone
> > >
> > > > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com>
> 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
> > > >> <v....@ymail.com.invalid> wrote:
> > > >>
> > > >>
> > > >> +1 on the process.
> > > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary
> > Li <
> > > >> garyli1019@outlook.com> wrote:
> > > >>
> > > >> +1
> > > >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> > > >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> > > >> To: users@hudi.apache.org <us...@hudi.apache.org>
> > > >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> > > >> Subject: Re: [DISCUSS] Formalizing the release process +1 on the
> > release
> > > >> process formalization.
> > > >>
> > > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <
> > vinoth@apache.org>
> > > 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
> > >
> >
> >
>
Re: [DISCUSS] Formalizing the release process
Posted by Raymond Xu <xu...@gmail.com>.
+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 <ud...@amazon.com.invalid>
wrote:
> +1 on the process.
>
> On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com> wrote:
>
> > +1 on the process
> >
> > Sent from my iPhone
> >
> > > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com> 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
> > >> <v....@ymail.com.invalid> wrote:
> > >>
> > >>
> > >> +1 on the process.
> > >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary
> Li <
> > >> garyli1019@outlook.com> wrote:
> > >>
> > >> +1
> > >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> > >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> > >> To: users@hudi.apache.org <us...@hudi.apache.org>
> > >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> > >> Subject: Re: [DISCUSS] Formalizing the release process +1 on the
> release
> > >> process formalization.
> > >>
> > >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <
> vinoth@apache.org>
> > 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
> >
>
>
Re: [DISCUSS] Formalizing the release process
Posted by "Mehrotra, Udit" <ud...@amazon.com.INVALID>.
+1 on the process.
On 9/8/20, 5:11 PM, "Vinoth Chandar" <vi...@apache.org> 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 <n3...@gmail.com> wrote:
> +1 on the process
>
> Sent from my iPhone
>
> > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com> 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
> >> <v....@ymail.com.invalid> wrote:
> >>
> >>
> >> +1 on the process.
> >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary Li <
> >> garyli1019@outlook.com> wrote:
> >>
> >> +1
> >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> >> To: users@hudi.apache.org <us...@hudi.apache.org>
> >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> >> Subject: Re: [DISCUSS] Formalizing the release process +1 on the release
> >> process formalization.
> >>
> >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org>
> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Vinoth Chandar <vi...@apache.org>.
>, 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 <n3...@gmail.com> wrote:
> +1 on the process
>
> Sent from my iPhone
>
> > On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com> 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
> >> <v....@ymail.com.invalid> wrote:
> >>
> >>
> >> +1 on the process.
> >> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary Li <
> >> garyli1019@outlook.com> wrote:
> >>
> >> +1
> >> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> >> Sent: Wednesday, September 2, 2020 3:11:06 AM
> >> To: users@hudi.apache.org <us...@hudi.apache.org>
> >> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> >> Subject: Re: [DISCUSS] Formalizing the release process +1 on the release
> >> process formalization.
> >>
> >>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org>
> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Nishith <n3...@gmail.com>.
+1 on the process
Sent from my iPhone
> On Sep 3, 2020, at 8:14 AM, Sivabalan <n....@gmail.com> 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
>> <v....@ymail.com.invalid> wrote:
>>
>>
>> +1 on the process.
>> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary Li <
>> garyli1019@outlook.com> wrote:
>>
>> +1
>> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
>> Sent: Wednesday, September 2, 2020 3:11:06 AM
>> To: users@hudi.apache.org <us...@hudi.apache.org>
>> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
>> Subject: Re: [DISCUSS] Formalizing the release process +1 on the release
>> process formalization.
>>
>>> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
Re: [DISCUSS] Formalizing the release process
Posted by Sivabalan <n....@gmail.com>.
+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
<v....@ymail.com.invalid> wrote:
>
> +1 on the process.
> Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary Li <
> garyli1019@outlook.com> wrote:
>
> +1
> Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
> Sent: Wednesday, September 2, 2020 3:11:06 AM
> To: users@hudi.apache.org <us...@hudi.apache.org>
> Cc: dev@hudi.apache.org <de...@hudi.apache.org>
> Subject: Re: [DISCUSS] Formalizing the release process +1 on the release
> process formalization.
>
> On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
Re: [DISCUSS] Formalizing the release process
Posted by Balaji Varadarajan <v....@ymail.com.INVALID>.
+1 on the process.
Balaji.V On Tuesday, September 1, 2020, 04:56:55 PM PDT, Gary Li <ga...@outlook.com> wrote:
+1
Gary LiFrom: Bhavani Sudha <bh...@gmail.com>
Sent: Wednesday, September 2, 2020 3:11:06 AM
To: users@hudi.apache.org <us...@hudi.apache.org>
Cc: dev@hudi.apache.org <de...@hudi.apache.org>
Subject: Re: [DISCUSS] Formalizing the release process +1 on the release process formalization.
On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Gary Li <ga...@outlook.com>.
+1
Gary Li
________________________________
From: Bhavani Sudha <bh...@gmail.com>
Sent: Wednesday, September 2, 2020 3:11:06 AM
To: users@hudi.apache.org <us...@hudi.apache.org>
Cc: dev@hudi.apache.org <de...@hudi.apache.org>
Subject: Re: [DISCUSS] Formalizing the release process
+1 on the release process formalization.
On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Gary Li <ga...@outlook.com>.
+1
Gary Li
________________________________
From: Bhavani Sudha <bh...@gmail.com>
Sent: Wednesday, September 2, 2020 3:11:06 AM
To: users@hudi.apache.org <us...@hudi.apache.org>
Cc: dev@hudi.apache.org <de...@hudi.apache.org>
Subject: Re: [DISCUSS] Formalizing the release process
+1 on the release process formalization.
On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Bhavani Sudha <bh...@gmail.com>.
+1 on the release process formalization.
On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
>
Re: [DISCUSS] Formalizing the release process
Posted by Bhavani Sudha <bh...@gmail.com>.
+1 on the release process formalization.
On Tue, Sep 1, 2020 at 10:21 AM Vinoth Chandar <vi...@apache.org> 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
>