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 Mon, 22 Feb 2016 18:06:32 GMT
Thanks Mariia

Do we have a documentation of the release process?

Boris.

On Mon, Feb 22, 2016 at 9:32 AM, Mariia Mykhailova <mamykhai@microsoft.com>
wrote:

> I've filed REEF-1215 to serve as umbrella JIRA for release 0.15. Boris,
> feel free to assign it to yourself, and thanks for volunteering :-)
>
> -Mariia
>
> -----Original Message-----
> From: Brian Cho [mailto:chobrian@gmail.com]
> Sent: Friday, February 19, 2016 10:51 PM
> To: dev@reef.apache.org
> Subject: Re: Should we postpone 0.14 release?
>
> Thanks Yunseong and Boris :)-Brian
>
> Sent from Outlook Mobile
>
>
>
>
> On Fri, Feb 19, 2016 at 7:18 PM -0800, "Markus Weimer" <markus@weimo.de>
> wrote:
>
> +1
>
> Thanks, Boris!
>
> Typed on glass with my thumbs. so please excuse brvt and typso.
> On Feb 19, 2016 18:57, "Yunseong Lee"  wrote:
>
> > Thanks everyone for the thoughtful comments! I agree with you all.
> >
> > Let's stick to the original schedule (REEF-1040 seems to be merged in
> > hours!) for 0.14 release.
> >
> > Also, thanks Boris for volunteering the next release manager!!
> >
> > Regards,
> > Yunseong
> >
> >
> > On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun  wrote:
> >
> > > Sounds good to me. Thanks.
> > >
> > >
> > > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman
> > > wrote:
> > >
> > > > 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
> > 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
> > > > 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"
> > > > > > Sent: ‎2/‎19/‎2016 6:23 PM
> > > > > > To: "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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Byung-Gon Chun
> > >
> >
>
>
>
>
>
>

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