[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesos-dev
Subject:    Re: Release / deprecation policy
From:       Zameer Manji <zmanji () apache ! org>
Date:       2015-11-25 22:06:55
Message-ID: CAK7Zj13V9K=a=nzJYPKTf-ME6L-G+k_ouUwSZvhEKDyB=iuSSw () mail ! gmail ! com
[Download RAW message or body]


I think the six month deprecation period is much better than what Mesos
provides currently. Apache Aurora has recently struggled with how to handle
the current Mesos deprecation policy, adopting a new policy of six months
will make it easier for us to adopt new Mesos releases without backwards
compatibility concerns.

On Wed, Nov 25, 2015 at 12:02 PM, Neil Conway <neil.conway@gmail.com> wrote:

> Hi Marco,
>
> Thanks for your comments! I agree that extending "mixed version"
> compatibility to N-6 versions is not warranted, at least right now.
>
> Going by lazy consensus: if anyone does NOT like the idea of a six
> release deprecation period (~six months), please speak up soon.
> Otherwise, I'll writeup a docs page that has our release/deprecation
> policy (MESOS-3995).
>
> Neil
>
> On Thu, Nov 19, 2015 at 6:32 PM, Marco Massenzio <marco@mesosphere.io>
> wrote:
> > Thanks, Neil, for getting the ball rolling on the matter.
> >
> > Absolutely in favor of extending the deprecation cycle of features to
> make
> > framework developers' and operators' lives easier.
> >
> > However,
> > -1 for extending compatibility up to N - 6
> >
> > 1) this prevents us to innovate and introduce functionality as quickly as
> > we still believe is necessary at this stage of development;
> >
> > 2) it makes release testing explode combinatorially (it's already bad
> > enough as it is right now).
> > as you correctly noted.
> >
> > Please note those are two different problems that we'd be addressing
> here,
> > and I don't really think that #2 has been really an issue so far (but,
> yes,
> > of course, it might in the future).
> >
> > Hence,
> > +1
> > in providing tooling to make cluster upgrades easier to automate.
> >
> > Thanks!
> >
> > --
> > *Marco Massenzio*
> > Distributed Systems Engineer
> > http://codetrips.com
> >
> > On Mon, Nov 16, 2015 at 9:24 PM, Neil Conway <neil.conway@gmail.com>
> wrote:
> >
> >> Folks,
> >>
> >> In the last community sync, we briefly discussed Mesos release policy.
> >> In particular, we talked about the current cadence of ~monthly
> >> releases and how that relates to (a) deprecation periods (b) support
> >> for running a "mixed version" cluster.
> >>
> >> As I understand it, the current policy is as follows:
> >>
> >> * To remove functionality, it should first be deprecated in one
> >> release and can then be removed in the next.
> >> * Mixed cluster versions are supported going back one release: e.g.,
> >> 0.25 masters and slaves must support communicating with 0.24 masters
> >> and slaves.
> >>
> >> Given that Mesos 1.0 is on the not-to-distant horizon (at which point
> >> we'll have different guarantees about API stability), I think we can
> >> revisit adopting a formal release policy at that point. In the
> >> interim, are there any pressing problems we need to address?
> >>
> >> Deprecation:
> >> ==========
> >>
> >> Removing deprecated functionality after one release makes sense when
> >> releases were made relatively infrequently, but with a monthly release
> >> cycle, this seems like an unreasonable rate of change to expect from
> >> authors of frameworks and tools.
> >>
> >> Proposal: After marking functionality as deprecated (e.g., in the
> >> documentation and "upgrade guide"), we should wait for at least 6
> >> monthly releases before removing it. So functionality that has been
> >> deprecated in 0.26 can be safely removed in 0.32.
> >>
> >> Mixed Cluster Versions:
> >> ==========
> >>
> >> We could adopt the same rule as above (if any two releases are made
> >> within six months of one another, they must be compatible), or else we
> >> could keep the same compatibility policy we have now (single release).
> >> I'm not sure the right answer here: keeping the current policy will
> >> make upgrading from, say, 0.26 to 0.32 somewhat painful, but (a) that
> >> can be ameliorated with deployment tooling (b) if we change to a 6-12
> >> month compatibility period, it will make testing the full
> >> compatibility matrix pretty difficult.
> >>
> >> Comments welcome!
> >>
> >> Neil
> >>
>
> --
> Zameer Manji
>
>


[prev in list] [next in list] [prev in thread] [next in thread]