On 06.03.2012, at 16:22, Luke Daley wrote:
> It's becoming clear that many users effectively ignore deprecation warnings.
> I think we may need to do something here.
>
> First, I don't think we can be too critical of users for this. I'm not sure
> we've been clear enough of exactly what deprecation means or how to deal with
> it, and for plugin authors it's even more confusing.
>
> I wonder if we could formalise our strategy soon after 1.0 to achieve the
> following:
>
> • Encourage users to move away from deprecated API as soon as they can so we
> don't get an influx when the item is removed
> • Make it clear what the compatibility implications of a deprecation are
> (e.g. when will the deprecated item go away, what's the backwards
> compatibility story)
> • Establish boundaries for version compatibility to help plugin authors
>
> Not saying we need to do anything now, but worth mulling over until the time
> when we do.
>
Oops, I more or less assumed that you'd get rid of everything deprecated so far
before you release 1.0, mostly because previous updates did already introduce
incompatible changes. This wouldn't be the right thing to do for future
post-1.0 releases, though.
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. The user
obviously needs to get the chance to at least see the deprecation warnings so
he's able to fix his build for the next version, though. How about keeping them
for two semi-major releases, e.g. keep stuff deprecated in 1.0 until 1.3?
This all depends on your future version strategy, though. If you end up like
Firefox or Chrome and we are at Gradle 5.0 at this time next year this
obviously wouldn't work out. ;)
My point for fast removal is that Gradle is moving at a very high pace and
keeping deprecated stuff around could slow down development since it would
require additional work to keep support for things that are probably even a bad
idea, from the best-practice-perspective.
Cheers,
Joern.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
