incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: deprecation policy
Date Tue, 19 Jun 2012 20:47:12 GMT
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" <> wrote:

>perhaps we put a timestamp / date of deprecation in the warning too?
>On Tue, Jun 19, 2012 at 2:04 PM, Bryce Curtis <>
>> 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 <> 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
>>> 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" <> 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.

View raw message