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 >
