groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: [VOTE] Apache Groovy Roadmap
Date Thu, 02 Feb 2017 15:03:53 GMT
I would like to have a clarification on 2 things before we really make a 
new version:

* is changing to java7 as default a breaking change and requires a new 
major version? (that implies 3.0 soon and 4.0 for java8 not long after)
* is it acceptable to have optional java8 only components (for example 
the parser) as part of a Groovy version with java7 or java6 as minimum 
requirement?
* do we  want to have a version in which the parrot parser is the 
optional default?


My answers would be: yes, yes and yes.

bye Jochen

On 02.02.2017 14:03, Graeme Rocher wrote:
> I'm in agreement that we should not commit to behaviour that we
> believe to be wrong and later break it (i.e. lambda's)
>
> So if we agree on a version that should be "the Parrot release"
> whether that is 2.6 or 3.0 we have to scope into that work resolving
> the semantics discussion.
>
> Cheers
>
> On Thu, Feb 2, 2017 at 12:47 PM, Jesper Steen Møller
> <jesper@selskabet.org> wrote:
>> Hi list
>>
>> On 2 Feb 2017, at 11.58, Paul King <paulk@asert.com.au> wrote:
>>
>> This thread has kind of gone into debate mode but I guess for the
>> record I would be -1 on any releases having parrot that weren't marked
>> as "experimental" or "incubating" until we thrash out future plans for
>> dealing with Java 8 features (default methods on interfaces/"real"
>> lambda expressions).
>>
>>
>> For this discussion, please note the difference between the parser
>> implementation and the new language features. Yes, at the moment, Parrot has
>> both.
>>
>> Upping the parser implementation only breaks compatibility in these cases:
>> 1) For clients who depend on the jarjar'ed antlr2 binaries or leaked
>> exceptions. This is IMHO bad form, but is likely required in projects the
>> groovy-eclipse plugin, as Jochen pointed out. These will need to update
>> anyway.
>> 2) A few grammar bugs in the old parser have been fixed, but AFAIK only for
>> confirmed bugs. Fixing a known bug is not a breaking change.
>> Obviously, the new parser can contain bugs, too, so testing should not be
>> taken lightly.
>>
>> Changing the language can be a breaking change. For now, Parrot adds the
>> syntax of Java 8 lambdas and method and constructor references to Groovy,
>> but with Groovy semantics,
>> Adding those can't be considered breaking as long as they only add new to
>> the language which weren't syntactically legal before?
>> But: As you rightly point out, the semantics of these haven't been explored
>> in depth, and there are pitfalls in addition to the one you mention: For
>> example: Adding lambdas as synonyms for closures (as they are now in the
>> parrot-branch), and later changing them to be Java 8 source compatible, e.g.
>> terms of how they resolve 'this', would be a breaking change.
>>
>> Where I'm getting at:
>> 1. Introducing Parrot needn't break anything.
>> 2. The roadmap suggested by Cédric doesn't stop us from having the Java 8
>> semantics-discussions right now, in time for the proposed 2.6.
>> 3. Major numbers should only be used if we mean to break stuff. Parrot
>> shouldn't.
>>
>> Kind regards
>> Jesper
>>
>>
>> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cchampeau@apache.org>
>> wrote:
>>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
>> to smoothly transition to higher requirements (and also, make our devs lives
>> easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we have:
>> backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>
>
>
>

Mime
View raw message