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 <[email protected]> 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 <[email protected]> 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 >>
