Hi, It's probably time to start planning for how we drop support for various tooling API consumer + provider combinations.
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. 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. 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. 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). - Dropping support for both consumers and providers <1.2-rc-1. We're definitely not ready to do this. -- 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
