> On 30 Jan 2017, at 21.32, Guillaume Laforge <glafo...@gmail.com> wrote: > > That's indeed another approach. > But that would mean two close major releases with breaking changes. Do you > think it'd be acceptable? >
If the testing is suffciently solid, how would shipping Groovy with Parrot (for Java 7) a breaking change (using jarjar'ed Antlr4)? Upping the JVM requirement will break things. Supporting Jigsaw will, too. So will a new MOP. Parrot does none of those things. -Jesper > > On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith <suder...@anc.org > <mailto:suder...@anc.org>> wrote: > >> On Jan 24, 2017, at 9:51 AM, Cédric Champeau <cedric.champ...@gmail.com >> <mailto: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. > > Maybe it is time to rethink the Groovy roadmap with respect to version > numbers? For example, something like > > 2.x Continue as is > 3.x Java 1.7 + Parrot. Maintain binary compatibility as much as possible. > (was 2.9) > 4.x Java 1.8 + Parrot + Jigsaw (was 3.0) > > This would make 4.x the new "blow up everything" release. Personally I > consider a move from Java 1.7 -> Java 1.8 a breaking change and should not be > done in a 2.x release. This roadmap would clearly separate upgrades and > breaking changes while still allowing people to start using Parrot in what is > essentially 2.x as soon as possible. > > Cheers, > Keith > >> >> (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 >> <mailto: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 >> <mailto: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 >> > > > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/> > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts>
