reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Shulman <shulm...@gmail.com>
Subject Re: Should we postpone 0.14 release?
Date Sat, 20 Feb 2016 02:50:59 GMT
Sure, will do that. So I assume we all agree that we will target 0.15 ~ two
weeks after 0.14 and it will be mostly driven by the multi-runtime feature.

Boris.

On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer <markus@weimo.de> wrote:

> That sounds like we have a volunteer for the release manager of 0.15 :)
>
> Markus
>
> On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <shulmanb@gmail.com> wrote:
> > I agree not to postpone 0.14 but lets target next release it 2-3 weeks.
> I don't mind if we do 0.15 or a minor release.
> >
> > -----Original Message-----
> > From: "Byung-Gon Chun" <bgchun@gmail.com>
> > Sent: ‎2/‎19/‎2016 6:23 PM
> > To: "dev@reef.apache.org" <dev@reef.apache.org>
> > Subject: Re: Should we postpone 0.14 release?
> >
> > I agree with Markus and Julia.
> > Let's not postpone this release.
> >
> >
> > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > Qiuhe.Wang@microsoft.com> wrote:
> >
> >> I agree. For test failure, we have to postpone. For feature, it can
> always
> >> catch next train if our release frequency is reasonable and the feature
> is
> >> not that critical.
> >>
> >> I believe we have resolved test failure about
> >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> >>
> >> Julia
> >>
> >> -----Original Message-----
> >> From: Markus Weimer [mailto:markus@weimo.de]
> >> Sent: Friday, February 19, 2016 5:58 PM
> >> To: dev@reef.apache.org
> >> Subject: Re: Should we postpone 0.14 release?
> >>
> >> Hi,
> >>
> >> I'm against postponing releases. It just turns into a never-ending story
> >> of postponements. Each release (even minor ones) have the same effort
> for
> >> us. Given that this one would be driven by a new feature, why not aim
> for a
> >> quick turnaround to 0.15? That way, we could also remove a lot of code
> we
> >> recently deprecated soon as well.
> >>
> >> Markus
> >>
> >
> >
> >
> > --
> > Byung-Gon Chun
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message