Hi Zameer, thanks for comments - I'd be happy to help the Aurora team upgrade to support Mesos 0.24+ I'll follow up on the issue you pointed us to.
*Marco Massenzio* *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>* On Thu, Oct 1, 2015 at 10:29 AM, Zameer Manji <zma...@apache.org> wrote: > +1 to Timothy's proposal. > > Here is a concrete example that can guide the policy. Aurora 0.9.0 was > released in July 2015 and was built against Mesos 0.22. At the time, I > don't think anyone was aware that 0.24 would come out in September 2015 and > break compatibility with with 0.22 w.r.t JSON/Protobuf. This means folks > who are using Aurora 0.9.0 in production can only upgrade to Mesos 0.23 at > latest. Now the Aurora project is faced with a problem. Aurora is much > smaller than the Mesos project and cannot keep up with the Mesos release > cadence. However if we don't do something right now we will continue to > prevent our users from upgrading their Mesos installations which may > contain upgrades that they need. Note that if we do release 0.9.1 with an > updated Mesos dependency, we might only be able to release against 0.23 so > we don't break users who are running 0.22 in production. > > If anyone has ideas on what we should do here please comment on AURORA-1503 > <https://issues.apache.org/jira/browse/AURORA-1503>. > > On Wed, Sep 30, 2015 at 6:35 PM, Timothy Chen <tnac...@gmail.com> wrote: > > > 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) > > >> > > > > -- > > Zameer Manji > > > > >
