mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Chen <tnac...@gmail.com>
Subject Re: Problems with deprecation cycles for critical/hard to adapt dependencies
Date Thu, 01 Oct 2015 01:35:34 GMT
I think besides changing to time based, we should provide a lot more visibility of the features
that we are starting to deprecate, and I think each release we can also highlight the remaining
releases/time each feature remaining lifetime so users are reminded on each release the full
list they should be aware.

Tim

> On Sep 30, 2015, at 5:17 PM, Niklas Nielsen <niklas@mesosphere.io> wrote:
> 
> @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.defelice@gmail.com>
> wrote:
> 
>> +1 for time-based deprecation cycle of O(months)
>> 
>>> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zmanji@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 <niklas@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)
>> 

Mime
View raw message