On Thu, Nov 1, 2012 at 8:38 PM, Adam Murdoch <[email protected]>wrote:
> > On 01/11/2012, at 7:21 PM, Hans Dockter wrote: > > We should urgently change our deprecation message to reflect reality. From > "will be removed in the next version" to "might be removed in the next > major version". We should do this already for 1.3. > > > Everything that is currently deprecated we are planning to remove in the > 2.0 release. I don't think there's anything we want to keep. So the message > above doesn't quite reflect our intentions: "might be removed" isn't strong > enough. > I see your point. Although from our backwards compatible contract point of view it is correct. > It "will be removed" > I guess what we remove will also depend on the feedback of our users. If 90% are saying that they are still using a deprecated feature we might think about removing it despite we would like to. 'Will be removed' sounds like that we don't care about feedback. > or "we plan to remove" or "is scheduled to be removed". > I would also go with scheduled to be removed. > > When we get closer to 2.0 this will change, where newly deprecated > features will have to stick around until 3.0. Same for deeply entrenched > features that we might deprecate like the old publication dsl. And there > are also incubating features that we deprecate that we intent to remove > sooner than 2.0. In the release notes, we've started being explicit about > exactly which version a given deprecated feature will be removed in. > I would say our mindset should be 'planned to be removed'. We are still open to listen to the community what they think about that plan. Hans > I would do the same with the deprecation message, e.g. "will be removed in > Gradle 2.0". > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
