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