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: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Date Wed, 23 May 2018 11:24:42 GMT
+1, regarding indy by default, I wonder if we could provide the "old" MOP
as a backward compatibility runtime jar...

Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <jesper@selskabet.org> a
écrit :

>
> > On 23 May 2018, at 12.23, Russel Winder <russel@winder.org.uk> wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to
> be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per
> se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a
> problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more
> than
> > anything has to be the order of the day. However I think there is a
> marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really,
> though
> > clearly we do it as we are already at RC-3, and it can be "milked". But
> 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and
> with some
> > breaking changes, in particular JDK8+ only, not to mention a parser
> based on
> > somewhat newer technology!  "Groovy drops support for JDK7" is probably
> a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big
> major
> > version number releases, but that it needs something to combat the "it's
> old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release
> soon and
> > worry about the metamodel changes later – unless they are already in
> place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on
> anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible,
> so that a new MOP2 runtime could still honor the MOP1 protocol, from some
> version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes
> now that we require Java 8 for Groovy 3.0. Again, we still need runtime
> support for the existing CallSite caching, or we'd have to force everybody
> to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be
> bootstrap-driven, i.e. by keeping the closure body as a method of the
> enclosing class, but by generating the closure in the fashion of
> LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce
> the cost of using closures (all those extra classfiles). We could possibly
> introduce a ClosureInterface for forwards compatibility, and deprecate the
> use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we
> could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
>

Mime
View raw message