groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <graeme.roc...@gmail.com>
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.

Regards,


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

Mime
View raw message