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 >
