+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 <jes...@selskabet.org> a écrit : > > > On 23 May 2018, at 12.23, Russel Winder <rus...@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 > > >
