On 23 May 2018, at 13.24, Cédric Champeau <[email protected]> wrote: > > +1, regarding indy by default, I wonder if we could provide the "old" MOP as > a backward compatibility runtime jar... >
Yes, but that would be pretty tricky if we want to target JPMS too, due to split packages. I wonder if it'd be possible to split it all up into (JPMS) modules like this: groovy-core groovy-compiler groovy-xml groovy-cli ... And then provide a "Groovy 2.x" compatibility JARs for stuff like MOP1 compatibility, modules that have moved, etc. and provide that in the groovy-all jar? -Jesper > Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <[email protected] > <mailto:[email protected]>> a écrit : > > > On 23 May 2018, at 12.23, Russel Winder <[email protected] > > <mailto:[email protected]>> 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 > >
