mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Conway <>
Subject Release / deprecation policy
Date Tue, 17 Nov 2015 05:24:25 GMT

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?


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!


View raw message