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 Tue, 31 Jan 2017 17:09:39 GMT

> On Jan 30, 2017, at 3:32 PM, Guillaume Laforge <glaforge@gmail.com> wrote:
> 
> That's indeed another approach.
> But that would mean two close major releases with breaking changes. Do you think it'd
be acceptable?

Yes, particularly since the 3.0 release wouldn't (hopefully) really break anything, I just
think the changes are large enough to warrant bumping the major version.  However, I see we
now have a new thread dedicated to this topic so I will continue there.

Keith

> 
> 
> On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith <suderman@anc.org <mailto:suderman@anc.org>>
wrote:
> 
>> On Jan 24, 2017, at 9:51 AM, C├ędric Champeau <cedric.champeau@gmail.com <mailto: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
>> 
> 
> 
> 
> 
> -- 
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> 
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>

Mime
View raw message