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