incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: deprecation policy
Date Tue, 19 Jun 2012 20:57:41 GMT
It is impossible to know when in the future you may be forced to remove
something that was previously deprecated.  I don't see any benefit in
documenting a 'removal timeframe' for a deprecated feature.
Simply recording the date/version where the feature was deprecated, as
Brian suggests should be enough.
Generally, I don't think we need to be aggressive with removing deprecated
features unless there is work involved in updating them.
IMHO we should simply state that 'this feature will be removed in a future
release, you should not be using it." and state somewhere else our overall
policy of maintaining the deprecated interface until it involves work to
keep it around. ie. this feature will NOT be patched/updated/fixed going
forward.

On Tue, Jun 19, 2012 at 1:47 PM, Filip Maj <fil@adobe.com> wrote:

> This all sounds reasonable. Shall we go ahead and employ this as "the
> policy" moving forward?
>
> Does it need a vote?
>
> On 6/19/12 12:34 PM, "Brian LeRoux" <b@brian.io> wrote:
>
> >perhaps we put a timestamp / date of deprecation in the warning too?
> >
> >On Tue, Jun 19, 2012 at 2:04 PM, Bryce Curtis <curtis.bryce@gmail.com>
> >wrote:
> >> I agree that deprecation doesn't have to be tied to a major release,
> >> but we should definitely give enough advanced notice.  6 months is
> >> arbitrary, but sounds like a reasonable period.  This carries the
> >> caveat that the deprecated item is documented and known so it's not a
> >> surprise to developers.  So, if we consider the deprecation of "ctx"
> >> in Android plugin, it probably shouldn't be removed in 2.0, but in
> >> whatever release falls after Nov.  This will minimize the pain to
> >> plugin developers, who are an important segment of our "customers".
> >>
> >> There may be instances where structural changes make it impossible to
> >> maintain deprecated APIs for the entire 6 month time, but I would
> >> consider this an exception and only if there's no way to maintain
> >> both.
> >>
> >> On Mon, Jun 18, 2012 at 5:30 PM, Filip Maj <fil@adobe.com> wrote:
> >>> To me version numbers are just a label. It's more about exposure,
> >>> communication and documentation.
> >>>
> >>> If we employ the standard deprecation techniques for the native
> >>>platforms
> >>> enough ahead of time, blog about upcoming breaking changes, provide
> >>> tutorials and documentation for how to migrate, I am fine with it.
> >>>
> >>> On 6/18/12 3:25 PM, "Brian LeRoux" <b@brian.io> wrote:
> >>>
> >>>>We don't really have one tho I think we loosely follow Semantic
> >>>>Versioning. In Android-land we recently merged in CordovaView which
> >>>>has an API change which will break many plugins.  In Semantic
> >>>>Versioning reality we are completely justified to kill an API in 2.x
> >>>>which would make a great deal of pain for plugin authors at that time.
> >>>>Major release, break all the things, seems bad.
> >>>>
> >>>>Anyhow, I'm thinking we look to create a policy that is time based. We
> >>>>make a change, its got 6 months of deprecation notices, and then its
> >>>>gone, regardless of version number.
> >>>>
> >>>>Thoughts?
> >>>
>
>


-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message