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
