I would love to see this improved soon. Thanks a lot Luke for bringing this up. Until 2.0 we might be deprecating more and more stuff and this an excellent (and relatively cheap) opportunity to earn some happiness points with our users.
Cheers! On Wed, Jan 16, 2013 at 3:00 PM, Luke Daley <[email protected]> wrote: > > On 16/01/2013, at 1:47 PM, Hans Dockter <[email protected]> wrote: > >> >> >> On Wed, Jan 16, 2013 at 2:43 PM, Luke Daley <[email protected]> >> wrote: >> >> On 16/01/2013, at 1:25 PM, Hans Dockter <[email protected]> wrote: >> >> > >> > >> > On Wed, Jan 16, 2013 at 2:08 PM, Luke Daley <[email protected]> >> > wrote: >> > There was talk around the 1.2 era where we were talking about improving >> > the user experience when dealing with deprecations. I think we should bump >> > up the priority of this and address it in the next release or two. >> > >> > I just updated an old project to 1.3 and received: “The >> > Project.dependsOnChildren() method has been deprecated and is scheduled to >> > be removed in Gradle 2.0.” >> > >> > As a user, that's far from helpful. What should I do now? How do I know >> > what the replacement is? We've already identified things that we could do >> > to improve this. >> > >> > My perception may be off on this in terms of high it is prioritised, but I >> > feel that it should be higher. It's an easy thing to “forget” about. >> > >> > This is something we should tackle. We could provide an URL where a user >> > can learn what are the alternatives. >> > >> > Anything else you have in mind to improve this? >> >> Something like: >> >> 1. Create a deprecation database in the userguide, where each deprecation is >> assigned an id and a reasonable explanation is given >> 2. Each deprecation can be linked to >> 3. Deprecation messages include this link >> >> Optional… >> >> 4. Users can acknowledge deprecations (by id) somehow and suppress the output >> 5. The deprecations section of the release notes is automated, based on the >> deprecations database >> 6. Profile report includes information about triggered deprecations >> 7. Build comparison report includes information about triggered deprecations >> >> Excellent. I would move 4.) to non-optional. > > Sure. > > The question I guess is whether to: > > 1. Bump something from 1.5 to do some work on this > 2. Give it some priority for 1.6 > 3. Leave it until after that > >> >> Hans >> >> -- >> Hans Dockter >> Founder, Gradle >> http://www.gradle.org, http://twitter.com/gradleware >> CEO, Gradleware - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
