incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: deprecation policy
Date Tue, 19 Jun 2012 19:34:42 GMT
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?
>>

Mime
View raw message