With Grails and GORM we plan to drop Java 7 support soon. So a 2.9 (or whatever) would be nice to add to the release plan
Cheers On Tue, Jan 24, 2017 at 3:51 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote: > 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 > > -- Graeme Rocher
