Release / deprecation policy

[Neil Conway <ne...@gmail.com>]

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

Re: Release / deprecation policy

[Zameer Manji <zm...@apache.org>]

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 <ne...@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 <ne...@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
>
>

Re: Release / deprecation policy

[Neil Conway <ne...@gmail.com>]

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 <ne...@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
>>

Re: Release / deprecation policy

[Marco Massenzio <ma...@mesosphere.io>]

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 <ne...@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
>