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