On Mon, 2017-01-30 at 21:32 +0100, Guillaume Laforge wrote:
> That's indeed another approach.
> But that would mean two close major releases with breaking changes.
> Do you
> think it'd be acceptable?
Major releases are what breaking changes are for. Or did I mean that
the other way around.
Havin
> On Jan 30, 2017, at 3:32 PM, Guillaume Laforge 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
> On 31 Jan 2017, at 09.31, Guillaume Laforge wrote:
>
> And speaking of this pull request: the Antlr v4 JARs are built against Java 7
> / JDK 7?
>
Antlr4 runtime jars are Java6 (classfile version 50).
I didn't try dropping down the parser down to 1.6, since I lack a 1.6 older
JVMs on my curr
;>>> >
>>>> >
>>>> > 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 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
ge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> /
Google+<https://plus.google.com/u/0/114130972232398734985/posts>
--
Graeme Rocher
If you reply to this email, your message will be added to the discussion below:
I am in agreement with doing a 3.0 compatible with Groovy 2.x and making
3.x into Groovy 4.x
Groovy 2.x users who will be in the majority for a long time shouldn't have
to wait for breaking changed to get Parrot
Also as stupid as it is having higher version numbers will also increase
perception o
> On 30 Jan 2017, at 21.32, Guillaume Laforge wrote:
>
> That's indeed another approach.
> But that would mean two close major releases with breaking changes. Do you
> think it'd be acceptable?
>
If the testing is suffciently solid, how would shipping Groovy with Parrot (for
Java 7) a breaki
That's indeed another approach.
But that would mean two close major releases with breaking changes. Do you
think it'd be acceptable?
On Mon, Jan 30, 2017 at 7:37 PM, Suderman Keith wrote:
>
> On Jan 24, 2017, at 9:51 AM, Cédric Champeau
> wrote:
>
> The main problem is parrot is that it requir
> On Jan 24, 2017, at 9:51 AM, Cédric Champeau
> 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
> r
Hi Jesper,
> I recognise that the Antlr4 parser AST building looks really neat in Java
> 8, but easthetics aside
That's why I choose Java 8 to rewrite the parser :)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/release-process-tp5737841p5
I plan to experiment with creating an "uber" jar (maybe using a
different name) for 2.5 that would have the parrot parser. It would be
like the indy jars for now, requiring a move into the correct
directory to enable. But it isn't high up on my priority list just
yet.
Cheers, Paul.
On Wed, Jan 2
But - I recognise that the Antlr4 parser AST building looks really neat in Java
8, but easthetics aside, wouldn’t it we a relatively easy task to port back to
Java 7?
-Jesper
> On 24 Jan 2017, at 16.59, Jochen Theodorou wrote:
>
>
>
> On 24.01.2017 15:51, Cédric Champeau wrote:
>> The main
On 24.01.2017 18:08, Cédric Champeau wrote:
[...]
you misunderstand one essential part here. The parrot module would
require java8, building Groovy would require Java8, executing Groovy
would not require Java8 as long as parrot is not used.
I do understand this. But we're talking abo
2017-01-24 16:59 GMT+01:00 Jochen Theodorou :
>
>
> On 24.01.2017 15:51, Cédric Champeau 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
On 24.01.2017 15:51, Cédric Champeau 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 simi
On 24.01.2017 15:45, Graeme Rocher wrote:
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.
nope, we are on the
With Grails and GORM we plan to drop Java 7 support soon.
So a 2.9 (or whatever) would be nice to add to the release plan
Cheers
On Tue, Jan 24, 2017 at 3:51 PM, Cédric Champeau
wrote:
> The main problem is parrot is that it requires Java 8, and 2.5 is planned to
> support 1.7. And bundling suc
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.
(as a side not
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 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
So if the changes are required for Java 9 then I guess breaking binary
compatibility is justifiable.
What I would like us to consider then is a Java 8 + Parrot release
that is binary compatible.
I think it would be a real shame that using Parrot required updating
to a version that is not compatib
2017-01-24 14:50 GMT+01:00 Graeme Rocher :
> 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 JD
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.
Is there a way to re
We can release 2.5.0-beta-1 and 3.0.0-alpha-1 concurrently. I see no
problem with that. And it would be cleaner. If we release, say, 2.5 final
with parrot as an optional module, nothing prevents people from using it
real projects. I don't think we want to pay the price of maintaining parrot
for 2.5
On 20.01.2017 22:04, Cédric Champeau wrote:
Let me rephrase what I said. My concern is not about complexity. My
concern is that parrot is an experimental parser, that requires Java 8,
and an additional dependency, antlr4, which conflicts with an existing
dependency, antlr2.
antlr2 and antrl4 ar
Let me rephrase what I said. My concern is not about complexity. My concern
is that parrot is an experimental parser, that requires Java 8, and an
additional dependency, antlr4, which conflicts with an existing dependency,
antlr2. I don't want to mix things like that. The new parser should be, as
a
The concern was added complexity but maybe it isn't much different to
normal. From my side, I need to play around some more to confirm either way.
At a minimum, we'd need to use java 8 to do the 2.5.x releases, and have
something sensible built, i.e. without the parrot option, for those
compiling
On 20.01.2017 13:14, Paul King wrote:
Wasn't the consensus to have parrot just in 3.0? So we could make the
2_5_X branch now?
may have missed something like a consensus I guess. But frankly I don´t
get why parrot should not even be optional in 2.5.x.
bye Jochen
opinion. But yes, we can do it like that. I guess we will need to set a
> time for that, once 2.5.0-beta-1 is ready to go, but first we need to merge
> the parrot branch ;)
>
> Wrt promoting our release process/scripts, I'd probably hold off a bit.
>> We're on a journey to
first two time-wise would be 2.5.0-beta-1 and 3.0.0-ea-1 in my
opinion. But yes, we can do it like that. I guess we will need to set a
time for that, once 2.5.0-beta-1 is ready to go, but first we need to
merge the parrot branch ;)
Wrt promoting our release process/scripts, I'd probably hold
+1 with a few comments below.
There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and
3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the first
two with you as "co-pilot" and swap roles for the third?
Wrt promoting our release process/scripts, I'
question if maybe our release process could be used as a model for git
based projects in the incubator. There was a thread about such a
skeleton not too long ago. Of course I am aware of that we have a
slightly different publication location than most of them will have, but
still. Also it would
33 matches
Mail list logo
