groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <>
Subject Re: release process
Date Tue, 24 Jan 2017 13:50:09 GMT
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.


On Fri, Jan 20, 2017 at 10:04 PM, Cédric Champeau
<> 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 <>:
>> 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" <> 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

View raw message