Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
> On 23 May 2018, at 12.23, Russel Winder <russel@xxxxxxxxxxxxx> 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
>> 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
> 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?