+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)
