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 >> >>
