I am in agreement with doing a 3.0 compatible with Groovy 2.x and making 3.x into Groovy 4.x
Groovy 2.x users who will be in the majority for a long time shouldn't have to wait for breaking changed to get Parrot Also as stupid as it is having higher version numbers will also increase perception of maturity. On Mon, 30 Jan 2017 at 23:10, Jesper Steen Møller <jes...@selskabet.org> wrote: > 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> wrote: > > > On Jan 24, 2017, at 9:51 AM, 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. > > > 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>: > > 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 > > > > > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> > > -- Graeme Rocher
