Understood. I still think it would be valuable to have a Parrot + Java 8 + Groovy 2.x release before Groovy 3.x
Maybe I am alone here, but it seems a shame that actual users won't get to benefit from Parrot for quite a few years. Cheers On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou <blackd...@gmx.org> wrote: > > > On 24.01.2017 14:50, Graeme Rocher wrote: >> >> Is the plan for 3.0 to break binary compatibility for existing libraries? >> >> Personally I don't think we should ever have a version that we call >> "blow everything up version" that would be a big red flag for me. >> Imagine Oracle announcing the Java JDK "blow everything up" edition. > > > you mean like Java9 with jigsaw? > >> Is there a way to retain some form of binary compatibility maybe >> through `groovy-compat` that contains the old call site caching? > > > That depends. If we want to change Closure to be a functional interface for > example, then not really. groovy-compat would have to transform the code > using Groovy. Or we have a transform that will force the program to use the > old closures, then we can still solve the issue. > > In other words, I think we should develop freely till we have what we want > and then think about how to make things compatible again. > > bye Jochen -- Graeme Rocher
