> It's probably time to start planning for how we drop support for various > tooling API consumer + provider combinations. >
+1 > There are only certain combinations that we can detect and do something > about: > > - The consumer can detect any provider version, as the provider has always > advertised its version. > - The provider can detect any consumer version from 1.2-rc-1 onwards, as > the consumer started advertising its version from then on. > - The provider can detect a consumer that is older than 1.0-milestone-8, > but it can't tell which version the consumer is. > - The provider cannot tell the difference between any consumer from > 1.0-milestone-8 and 1.1. > > I think we want to support a pretty wide range of provider versions - > these are the versions of Gradle that run the build. So, tooling that uses > a recent version of the tooling API consumer should be able to use builds > for a wide range of Gradle versions, possibly all of them. > +1 For the consumer, I think we can expect tooling to move more quickly to > newer versions. So, a recent Gradle version may not support consumers older > than, say, 1 year or so. In particular, dropping support for consumers > older than 1.0-milestone-8 would make sense, as we can clean up some of the > older protocol implementations. > I would like to draw a line at Gradle 1.0 but if we cannot tell a difference between M8 and 1.1 then this plan works. > An open question is how we sequence this. A few options: > > 1. The tooling API provider from 1.6-rc-1 onwards will stop handling model > requests that use the old (pre 1.0-m8) connection methods, by throwing an > exception with a helpful error message. We document this breaking change in > the release notes. > > 2. The tooling API provider from 1.6-rc-1 continues to handle model > requests that use the old connection methods, but also includes a > deprecation warning in the logging output that the tooling API client > receives. In some later release (maybe Gradle 2.0) the provider starts > throwing an exception. We document the deprecation in the release notes > plus when we intend to remove support. > > 3. We wait until we're closer to Gradle 2.0 and do one of the above. > Another option (not necessarily a good one): warn but don't prevent. Print a warning saying that the client is unsupported, use it at your own risk, here's how to upgrade, blah. Also, the exceptions from provider/client could be wrapped with similar info (e.g. client is unsupported). I think I would go for #1. I don't think we have to wait for 2.0. > There's not any huge benefit for dropping support for consumers <1.0-m8, > as far as simplifying the internals go. There are 2 cases that would have > some nice benefits: > > - Dropping support for both consumers and providers <1.0-m8. I don't think > we're quite ready to do this for the provider (1.0-m8 was released 1 year > ago). > I think we're pretty close. > - Dropping support for both consumers and providers <1.2-rc-1. We're > definitely not ready to do this. > Agreed. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > -- Szczepan Faber Principal engineer@gradleware; Lead@mockito Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
