groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: release process
Date Tue, 24 Jan 2017 13:55:53 GMT
2017-01-24 14:50 GMT+01:00 Graeme Rocher <graeme.rocher@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.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