groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suderman Keith <suder...@anc.org>
Subject Re: release process
Date Mon, 30 Jan 2017 18:37:54 GMT

> On Jan 24, 2017, at 9:51 AM, C├ędric Champeau <cedric.champeau@gmail.com> wrote:
> 
> The main problem is parrot is that it requires Java 8, and 2.5 is planned to support
1.7. And bundling such a core thing as an experimental, optional module is a no-go for me
(imagine the bug reports...). We could have a 2.9 release (or something similar) with Parrot
sooner, though.

Maybe it is time to rethink the Groovy roadmap with respect to version numbers?  For example,
something like

2.x Continue as is
3.x Java 1.7 + Parrot.  Maintain binary compatibility as much as possible. (was 2.9)
4.x Java 1.8 + Parrot + Jigsaw (was 3.0)

This would make 4.x the new "blow up everything" release.  Personally I consider a move from
Java 1.7 -> Java 1.8 a breaking change and should not be done in a 2.x release.  This roadmap
would clearly separate upgrades and breaking changes while still allowing people to start
using Parrot in what is essentially 2.x as soon as possible.

Cheers,
Keith

> 
> (as a side note, any release of Groovy that would require Java 8 would be a no-go for
Gradle in short term, be it 2.x or 3.x)
> 
> 2017-01-24 15:45 GMT+01:00 Graeme Rocher <graeme.rocher@gmail.com <mailto:graeme.rocher@gmail.com>>:
> Understood.
> 
> I still think it would be valuable to have a Parrot + Java 8 + Groovy
> 2.x release before Groovy 3.x
> 
> Maybe I am alone here, but it seems a shame that actual users won't
> get to benefit from Parrot for quite a few years.
> 
> Cheers
> 
> On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou <blackdrag@gmx.org <mailto:blackdrag@gmx.org>>
wrote:
> >
> >
> > On 24.01.2017 14:50, Graeme Rocher wrote:
> >>
> >> 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.
> >
> >
> > you mean like Java9 with jigsaw?
> >
> >> Is there a way to retain some form of binary compatibility maybe
> >> through `groovy-compat` that contains the old call site caching?
> >
> >
> > That depends. If we want to change Closure to be a functional interface for
> > example, then not really. groovy-compat would have to transform the code
> > using Groovy. Or we have a transform that will force the program to use the
> > old closures, then we can still solve the issue.
> >
> > In other words, I think we should develop freely till we have what we want
> > and then think about how to make things compatible again.
> >
> > bye Jochen
> 
> 
> 
> --
> Graeme Rocher
> 


Mime
View raw message