@vinod, ben, jie - Any thoughts on this?

I am in favor of the time based deprecation as well and can come up with a
proposal, taken there are no objections.

Niklas

On 28 September 2015 at 21:09, James DeFelice <james.defel...@gmail.com>
wrote:

> +1 for time-based deprecation cycle of O(months)
>
> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zma...@apache.org> wrote:
>
> > Niklas,
> >
> > Thanks for starting this thread. I think Mesos can best move forward if
> it
> > switches from release based deprecation cycle to a time based deprecation
> > cycle. This means that APIs would be deprecated after a time period (ie 4
> > months) instead of at a specific release. This is the model that Google's
> > Guava library uses and I think it works really well. It ensures that the
> > ecosystem and community has sufficient time to react to deprecations
> while
> > still allowing them to move forward at a reasonable pace.
> >
> > On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <nik...@mesosphere.io>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > With a (targeted) release cadence of *one month*, we should revisit our
> > > deprecation cycles of 3 releases (e.g. in version N, we warn. In
> version
> > > N+1, support both old and new API. In Version N+2, we break
> > compatibility).
> > > Sometimes we cannot do the first step, and we deprecate in version N+1
> > and
> > > thus in 2 releases. With the new cadence, that is no longer around two
> > > quarters but two months which is too short for 3rd party tooling to
> > adapt.
> > >
> > > Even though our release cycles have been longer than one month in the
> > past,
> > > we are running into issues with deprecation due to lack of outreach
> (i.e.
> > > our communication to framework and 3rd party tooling communities) or
> > > because we are simply unaware on the internal dependencies they have on
> > > Mesos.
> > >
> > > We/I became aware of this, when we saw a planned deprecation of
> > /state.json
> > > in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools will
> > > break because of this. This, on top of the problems we have run into
> > > recently with the Zookeeper master info change from binary protobuf to
> > > json.
> > >
> > > Even though we document this in our upgrade.md, the
> visibility/knowledge
> > > of
> > > this document seem too low and we probably need to do more.
> > >
> > > Do you guys have thoughts/ideas on how we can address this?
> > >
> > > Cheers,
> > > Niklas
> > >
> > > --
> > > Zameer Manji
> > >
> > >
> >
>
>
>
> --
> James DeFelice
> 585.241.9488 (voice)
> 650.649.6071 (fax)
>

Reply via email to