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