The main problem is parrot is that it requires Java 8, and 2.5 is planned to support 1.7. And bundling such a core thing as an experimental, optional module is a no-go for me (imagine the bug reports...). We could have a 2.9 release (or something similar) with Parrot sooner, though.
(as a side note, any release of Groovy that would require Java 8 would be a no-go for Gradle in short term, be it 2.x or 3.x) 2017-01-24 15:45 GMT+01:00 Graeme Rocher <graeme.roc...@gmail.com>: > 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 >
