groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Indy vs default build
Date Mon, 29 May 2017 16:27:03 GMT

On 29.05.2017 09:21, C├ędric Champeau wrote:
> "Indy by default" doesn't mean anything. It's either "get rid of old
> call site caching/only keep indy" or, "keep as is".

Completely ripping out the old callsite caching means old code will no 
longer work. Having both, but using indy as default will not be a 
breaking change for binary compatibility. And the old callsite caching 
could be rewritten to use indy as well. We would still get rid of most 
of the callsite caching code then. This means we can make this a two 
step approach. First have both, but let the old code use indy. And then 
get rid of the old part completely ind the big breaking change version

> Also, bumping to Java 8 only may be an issue for some. At least, it
> would prevent Gradle from upgrading to Groovy 3. Which may, or may not
> be an issue.

If it is a big binary breaking version this Gradle will not adapt that 
Groovy version anytime anyway. Right?

bye Jochen

View raw message