incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <>
Subject Re: deprecation policy
Date Tue, 19 Jun 2012 18:04:17 GMT
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

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 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" <> 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