huxi wrote > > Due to the easy way to use a specific Gradle version via wrapper, I'd > personally keep deprecated stuff around for as short as possible. >
This reasoning works (to some extent) for builds, but not for third-party plugins. As a plugin author, you want deprecated APIs to stay around as long as possible. As soon as you have to support multiple incompatible versions of a dependency (Gradle in this case), things get a lot more complicated and painful, in particular if you (need to) use static typing. In short, if Gradle moves too quickly in terms of incompatible changes, the plugin ecosystem will suffer heavily. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Deprecation-tp5541189p5546182.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
