You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Niklas Nielsen <ni...@mesosphere.io> on 2015/10/01 02:17:40 UTC
Re: Problems with deprecation cycles for critical/hard to adapt dependencies
@vinod, ben, jie - Any thoughts on this?
I am in favor of the time based deprecation as well and can come up with a
proposal, taken there are no objections.
Niklas
On 28 September 2015 at 21:09, James DeFelice <ja...@gmail.com>
wrote:
> +1 for time-based deprecation cycle of O(months)
>
> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zm...@apache.org> wrote:
>
> > Niklas,
> >
> > Thanks for starting this thread. I think Mesos can best move forward if
> it
> > switches from release based deprecation cycle to a time based deprecation
> > cycle. This means that APIs would be deprecated after a time period (ie 4
> > months) instead of at a specific release. This is the model that Google's
> > Guava library uses and I think it works really well. It ensures that the
> > ecosystem and community has sufficient time to react to deprecations
> while
> > still allowing them to move forward at a reasonable pace.
> >
> > On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <ni...@mesosphere.io>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > With a (targeted) release cadence of *one month*, we should revisit our
> > > deprecation cycles of 3 releases (e.g. in version N, we warn. In
> version
> > > N+1, support both old and new API. In Version N+2, we break
> > compatibility).
> > > Sometimes we cannot do the first step, and we deprecate in version N+1
> > and
> > > thus in 2 releases. With the new cadence, that is no longer around two
> > > quarters but two months which is too short for 3rd party tooling to
> > adapt.
> > >
> > > Even though our release cycles have been longer than one month in the
> > past,
> > > we are running into issues with deprecation due to lack of outreach
> (i.e.
> > > our communication to framework and 3rd party tooling communities) or
> > > because we are simply unaware on the internal dependencies they have on
> > > Mesos.
> > >
> > > We/I became aware of this, when we saw a planned deprecation of
> > /state.json
> > > in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools will
> > > break because of this. This, on top of the problems we have run into
> > > recently with the Zookeeper master info change from binary protobuf to
> > > json.
> > >
> > > Even though we document this in our upgrade.md, the
> visibility/knowledge
> > > of
> > > this document seem too low and we probably need to do more.
> > >
> > > Do you guys have thoughts/ideas on how we can address this?
> > >
> > > Cheers,
> > > Niklas
> > >
> > > --
> > > Zameer Manji
> > >
> > >
> >
>
>
>
> --
> James DeFelice
> 585.241.9488 (voice)
> 650.649.6071 (fax)
>
Re: Problems with deprecation cycles for critical/hard to adapt dependencies
Posted by Marco Massenzio <ma...@mesosphere.io>.
Hi Zameer,
thanks for comments - I'd be happy to help the Aurora team upgrade to
support Mesos 0.24+
I'll follow up on the issue you pointed us to.
*Marco Massenzio*
*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
On Thu, Oct 1, 2015 at 10:29 AM, Zameer Manji <zm...@apache.org> wrote:
> +1 to Timothy's proposal.
>
> Here is a concrete example that can guide the policy. Aurora 0.9.0 was
> released in July 2015 and was built against Mesos 0.22. At the time, I
> don't think anyone was aware that 0.24 would come out in September 2015 and
> break compatibility with with 0.22 w.r.t JSON/Protobuf. This means folks
> who are using Aurora 0.9.0 in production can only upgrade to Mesos 0.23 at
> latest. Now the Aurora project is faced with a problem. Aurora is much
> smaller than the Mesos project and cannot keep up with the Mesos release
> cadence. However if we don't do something right now we will continue to
> prevent our users from upgrading their Mesos installations which may
> contain upgrades that they need. Note that if we do release 0.9.1 with an
> updated Mesos dependency, we might only be able to release against 0.23 so
> we don't break users who are running 0.22 in production.
>
> If anyone has ideas on what we should do here please comment on AURORA-1503
> <https://issues.apache.org/jira/browse/AURORA-1503>.
>
> On Wed, Sep 30, 2015 at 6:35 PM, Timothy Chen <tn...@gmail.com> wrote:
>
> > I think besides changing to time based, we should provide a lot more
> > visibility of the features that we are starting to deprecate, and I think
> > each release we can also highlight the remaining releases/time each
> feature
> > remaining lifetime so users are reminded on each release the full list
> they
> > should be aware.
> >
> > Tim
> >
> > > On Sep 30, 2015, at 5:17 PM, Niklas Nielsen <ni...@mesosphere.io>
> > wrote:
> > >
> > > @vinod, ben, jie - Any thoughts on this?
> > >
> > > I am in favor of the time based deprecation as well and can come up
> with
> > a
> > > proposal, taken there are no objections.
> > >
> > > Niklas
> > >
> > > On 28 September 2015 at 21:09, James DeFelice <
> james.defelice@gmail.com>
> > > wrote:
> > >
> > >> +1 for time-based deprecation cycle of O(months)
> > >>
> > >>> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zm...@apache.org>
> > wrote:
> > >>>
> > >>> Niklas,
> > >>>
> > >>> Thanks for starting this thread. I think Mesos can best move forward
> if
> > >> it
> > >>> switches from release based deprecation cycle to a time based
> > deprecation
> > >>> cycle. This means that APIs would be deprecated after a time period
> > (ie 4
> > >>> months) instead of at a specific release. This is the model that
> > Google's
> > >>> Guava library uses and I think it works really well. It ensures that
> > the
> > >>> ecosystem and community has sufficient time to react to deprecations
> > >> while
> > >>> still allowing them to move forward at a reasonable pace.
> > >>>
> > >>> On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <
> niklas@mesosphere.io>
> > >>> wrote:
> > >>>
> > >>>> Hi everyone,
> > >>>>
> > >>>> With a (targeted) release cadence of *one month*, we should revisit
> > our
> > >>>> deprecation cycles of 3 releases (e.g. in version N, we warn. In
> > >> version
> > >>>> N+1, support both old and new API. In Version N+2, we break
> > >>> compatibility).
> > >>>> Sometimes we cannot do the first step, and we deprecate in version
> N+1
> > >>> and
> > >>>> thus in 2 releases. With the new cadence, that is no longer around
> two
> > >>>> quarters but two months which is too short for 3rd party tooling to
> > >>> adapt.
> > >>>>
> > >>>> Even though our release cycles have been longer than one month in
> the
> > >>> past,
> > >>>> we are running into issues with deprecation due to lack of outreach
> > >> (i.e.
> > >>>> our communication to framework and 3rd party tooling communities) or
> > >>>> because we are simply unaware on the internal dependencies they have
> > on
> > >>>> Mesos.
> > >>>>
> > >>>> We/I became aware of this, when we saw a planned deprecation of
> > >>> /state.json
> > >>>> in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools
> will
> > >>>> break because of this. This, on top of the problems we have run into
> > >>>> recently with the Zookeeper master info change from binary protobuf
> to
> > >>>> json.
> > >>>>
> > >>>> Even though we document this in our upgrade.md, the
> > >> visibility/knowledge
> > >>>> of
> > >>>> this document seem too low and we probably need to do more.
> > >>>>
> > >>>> Do you guys have thoughts/ideas on how we can address this?
> > >>>>
> > >>>> Cheers,
> > >>>> Niklas
> > >>>>
> > >>>> --
> > >>>> Zameer Manji
> > >>
> > >>
> > >>
> > >> --
> > >> James DeFelice
> > >> 585.241.9488 (voice)
> > >> 650.649.6071 (fax)
> > >>
> >
> > --
> > Zameer Manji
> >
> >
>
Re: Problems with deprecation cycles for critical/hard to adapt dependencies
Posted by Zameer Manji <zm...@apache.org>.
+1 to Timothy's proposal.
Here is a concrete example that can guide the policy. Aurora 0.9.0 was
released in July 2015 and was built against Mesos 0.22. At the time, I
don't think anyone was aware that 0.24 would come out in September 2015 and
break compatibility with with 0.22 w.r.t JSON/Protobuf. This means folks
who are using Aurora 0.9.0 in production can only upgrade to Mesos 0.23 at
latest. Now the Aurora project is faced with a problem. Aurora is much
smaller than the Mesos project and cannot keep up with the Mesos release
cadence. However if we don't do something right now we will continue to
prevent our users from upgrading their Mesos installations which may
contain upgrades that they need. Note that if we do release 0.9.1 with an
updated Mesos dependency, we might only be able to release against 0.23 so
we don't break users who are running 0.22 in production.
If anyone has ideas on what we should do here please comment on AURORA-1503
<https://issues.apache.org/jira/browse/AURORA-1503>.
On Wed, Sep 30, 2015 at 6:35 PM, Timothy Chen <tn...@gmail.com> wrote:
> I think besides changing to time based, we should provide a lot more
> visibility of the features that we are starting to deprecate, and I think
> each release we can also highlight the remaining releases/time each feature
> remaining lifetime so users are reminded on each release the full list they
> should be aware.
>
> Tim
>
> > On Sep 30, 2015, at 5:17 PM, Niklas Nielsen <ni...@mesosphere.io>
> wrote:
> >
> > @vinod, ben, jie - Any thoughts on this?
> >
> > I am in favor of the time based deprecation as well and can come up with
> a
> > proposal, taken there are no objections.
> >
> > Niklas
> >
> > On 28 September 2015 at 21:09, James DeFelice <ja...@gmail.com>
> > wrote:
> >
> >> +1 for time-based deprecation cycle of O(months)
> >>
> >>> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zm...@apache.org>
> wrote:
> >>>
> >>> Niklas,
> >>>
> >>> Thanks for starting this thread. I think Mesos can best move forward if
> >> it
> >>> switches from release based deprecation cycle to a time based
> deprecation
> >>> cycle. This means that APIs would be deprecated after a time period
> (ie 4
> >>> months) instead of at a specific release. This is the model that
> Google's
> >>> Guava library uses and I think it works really well. It ensures that
> the
> >>> ecosystem and community has sufficient time to react to deprecations
> >> while
> >>> still allowing them to move forward at a reasonable pace.
> >>>
> >>> On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <ni...@mesosphere.io>
> >>> wrote:
> >>>
> >>>> Hi everyone,
> >>>>
> >>>> With a (targeted) release cadence of *one month*, we should revisit
> our
> >>>> deprecation cycles of 3 releases (e.g. in version N, we warn. In
> >> version
> >>>> N+1, support both old and new API. In Version N+2, we break
> >>> compatibility).
> >>>> Sometimes we cannot do the first step, and we deprecate in version N+1
> >>> and
> >>>> thus in 2 releases. With the new cadence, that is no longer around two
> >>>> quarters but two months which is too short for 3rd party tooling to
> >>> adapt.
> >>>>
> >>>> Even though our release cycles have been longer than one month in the
> >>> past,
> >>>> we are running into issues with deprecation due to lack of outreach
> >> (i.e.
> >>>> our communication to framework and 3rd party tooling communities) or
> >>>> because we are simply unaware on the internal dependencies they have
> on
> >>>> Mesos.
> >>>>
> >>>> We/I became aware of this, when we saw a planned deprecation of
> >>> /state.json
> >>>> in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools will
> >>>> break because of this. This, on top of the problems we have run into
> >>>> recently with the Zookeeper master info change from binary protobuf to
> >>>> json.
> >>>>
> >>>> Even though we document this in our upgrade.md, the
> >> visibility/knowledge
> >>>> of
> >>>> this document seem too low and we probably need to do more.
> >>>>
> >>>> Do you guys have thoughts/ideas on how we can address this?
> >>>>
> >>>> Cheers,
> >>>> Niklas
> >>>>
> >>>> --
> >>>> Zameer Manji
> >>
> >>
> >>
> >> --
> >> James DeFelice
> >> 585.241.9488 (voice)
> >> 650.649.6071 (fax)
> >>
>
> --
> Zameer Manji
>
>
Re: Problems with deprecation cycles for critical/hard to adapt dependencies
Posted by Timothy Chen <tn...@gmail.com>.
I think besides changing to time based, we should provide a lot more visibility of the features that we are starting to deprecate, and I think each release we can also highlight the remaining releases/time each feature remaining lifetime so users are reminded on each release the full list they should be aware.
Tim
> On Sep 30, 2015, at 5:17 PM, Niklas Nielsen <ni...@mesosphere.io> wrote:
>
> @vinod, ben, jie - Any thoughts on this?
>
> I am in favor of the time based deprecation as well and can come up with a
> proposal, taken there are no objections.
>
> Niklas
>
> On 28 September 2015 at 21:09, James DeFelice <ja...@gmail.com>
> wrote:
>
>> +1 for time-based deprecation cycle of O(months)
>>
>>> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zm...@apache.org> wrote:
>>>
>>> Niklas,
>>>
>>> Thanks for starting this thread. I think Mesos can best move forward if
>> it
>>> switches from release based deprecation cycle to a time based deprecation
>>> cycle. This means that APIs would be deprecated after a time period (ie 4
>>> months) instead of at a specific release. This is the model that Google's
>>> Guava library uses and I think it works really well. It ensures that the
>>> ecosystem and community has sufficient time to react to deprecations
>> while
>>> still allowing them to move forward at a reasonable pace.
>>>
>>> On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <ni...@mesosphere.io>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> With a (targeted) release cadence of *one month*, we should revisit our
>>>> deprecation cycles of 3 releases (e.g. in version N, we warn. In
>> version
>>>> N+1, support both old and new API. In Version N+2, we break
>>> compatibility).
>>>> Sometimes we cannot do the first step, and we deprecate in version N+1
>>> and
>>>> thus in 2 releases. With the new cadence, that is no longer around two
>>>> quarters but two months which is too short for 3rd party tooling to
>>> adapt.
>>>>
>>>> Even though our release cycles have been longer than one month in the
>>> past,
>>>> we are running into issues with deprecation due to lack of outreach
>> (i.e.
>>>> our communication to framework and 3rd party tooling communities) or
>>>> because we are simply unaware on the internal dependencies they have on
>>>> Mesos.
>>>>
>>>> We/I became aware of this, when we saw a planned deprecation of
>>> /state.json
>>>> in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools will
>>>> break because of this. This, on top of the problems we have run into
>>>> recently with the Zookeeper master info change from binary protobuf to
>>>> json.
>>>>
>>>> Even though we document this in our upgrade.md, the
>> visibility/knowledge
>>>> of
>>>> this document seem too low and we probably need to do more.
>>>>
>>>> Do you guys have thoughts/ideas on how we can address this?
>>>>
>>>> Cheers,
>>>> Niklas
>>>>
>>>> --
>>>> Zameer Manji
>>
>>
>>
>> --
>> James DeFelice
>> 585.241.9488 (voice)
>> 650.649.6071 (fax)
>>