So if the changes are required for Java 9 then I guess breaking binary compatibility is justifiable.
What I would like us to consider then is a Java 8 + Parrot release that is binary compatible. I think it would be a real shame that using Parrot required updating to a version that is not compatible with anything else out there and will hinder adoption and progress on the new parser. My vote is that we consider the release plan to include a release between 2.5 and 3.0 where Java 8 is the minimum and Parrot can be included by default. Otherwise Parrot won't be used in the real world for years to come IMO. Cheers On Tue, Jan 24, 2017 at 2:55 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote: > > > 2017-01-24 14:50 GMT+01:00 Graeme Rocher <graeme.roc...@gmail.com>: >> >> 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. > > > They did. It's called Java 9, and Groovy won't play well with it, as a > module. That's one of the many reasons why we need to break binary > compatibility. >> >> >> Is there a way to retain some form of binary compatibility maybe >> through `groovy-compat` that contains the old call site caching? > > > The problem is more split packages. And the cost of maintenance of old call > site caching. > >> >> >> If 3.0 is to be a breaking binary incompatible release then I see real >> value in adding parrot to a version of Groovy that is binary >> compatible since it will be a VERY long time before folks are able to >> even consider 3.0 so personally I am with Jochen on this one. >> >> Regards, >> >> >> On Fri, Jan 20, 2017 at 10:04 PM, Cédric Champeau >> <cedric.champ...@gmail.com> wrote: >> > Let me rephrase what I said. My concern is not about complexity. My >> > concern >> > is that parrot is an experimental parser, that requires Java 8, and an >> > additional dependency, antlr4, which conflicts with an existing >> > dependency, >> > antlr2. I don't want to mix things like that. The new parser should be, >> > as >> > all Java 8+ things, Groovy 3 only. There's little, if any, value in >> > mixing >> > this in 2.5, but there's a high risk for users. Risks of unwanted >> > behavior, >> > bigger distribution, additional flags, ... >> > >> > I thought I was clear but it seems not: >> > - 2.5 should be Java 7 and macros. >> > - 3.0 should be the blow everything up version, that bumps to Java 8, >> > adds >> > the new parser, and removes the old call site caching stuff >> > >> > It will be easier for us too, because it's pretty clear where we can >> > merge >> > experimental stuff, as well as releasing betas, alphas, whatever you >> > want to >> > call them. But let's not mix stable and unstable things in a single >> > distribution. Git branches are not so hard. >> > >> > 2017-01-20 21:52 GMT+01:00 Paul King <pa...@asert.com.au>: >> >> >> >> The concern was added complexity but maybe it isn't much different to >> >> normal. From my side, I need to play around some more to confirm either >> >> way. >> >> >> >> At a minimum, we'd need to use java 8 to do the 2.5.x releases, and >> >> have >> >> something sensible built, i.e. without the parrot option, for those >> >> compiling the src from 7 or running on 7. So probably some build >> >> changes and >> >> plugin capability. >> >> >> >> Cheers Paul. >> >> >> >> On 21 Jan 2017 5:01 AM, "Jochen Theodorou" <blackd...@gmx.org> wrote: >> >>> >> >>> On 20.01.2017 13:14, Paul King wrote: >> >>>> >> >>>> Wasn't the consensus to have parrot just in 3.0? So we could make the >> >>>> 2_5_X branch now? >> >>> >> >>> >> >>> may have missed something like a consensus I guess. But frankly I >> >>> don´t >> >>> get why parrot should not even be optional in 2.5.x. >> >>> >> >>> bye Jochen >> >>> >> > >> >> >> >> -- >> Graeme Rocher > > -- Graeme Rocher
