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.con...@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 <ma...@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.con...@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 > >