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.
Is there a way to retain some form of binary compatibility maybe through `groovy-compat` that contains the 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
