On 07/03/2012, at 12:22 AM, Daz DeBoer wrote: > Maybe a way for plugins to silence deprecation warnings generated by the > plugin code would be nice.
Silencing warnings produced during plugin application would be easy, but silencing warnings produced by plugins after this point will be tricky… though possible to be sure. > Then, if we guarantee that "elements deprecated in 1.x will be removed in 2.0 > (but no sooner)", the plugin author would only need to create one version of > the plugin for Gradle 1.x, and another version for Gradle 2.x. (This is > assuming the plugin doesn't want to take advantage of new features in a 1.x > minor release.) Yeah, that will have to one of the goals I guess. Plugin developers will have to know how forwards compatible their plugins are going to be. The other side that you point out is that we'll have to cater for plugins not using new features introduced late in 1.x in order to remain backwards compatible. This means that a feature may not be as battle tested as we think by the time we remove what was replaced by the feature. Perhaps something to keep in mind is making it easier for plugin authors to optionally take advantage of new features. I think this will be more a stylistic/best practices/documentation issue on our side and less of a technical issue. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
