groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Suderman <suder...@anc.org>
Subject Re: [VOTE] Apache Groovy Roadmap
Date Thu, 02 Feb 2017 16:12:14 GMT

> On Feb 2, 2017, at 6:47 AM, Jesper Steen Møller <jesper@selskabet.org> wrote:
> 
> 3. Major numbers should only be used if we mean to break stuff. Parrot shouldn't.


> On Feb 2, 2017, at 10:03 AM, Jochen Theodorou <blackdrag@gmx.org> wrote:
> 
> 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)


The Semantic Version spec states that the major version MUST be incremented if the release
contains breaking changes, but the inverse is not true, that is, the major version can be
incremented even if the release does not include breaking changes.  I am of the opinion that
the inclusion of Parrot + requiring Java 7 are big enough developments to warrant an increase
in the major version even if nothing breaks.

Cheers,
Keith


> 
> Kind regards
> Jesper
> 
>> 
>> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cchampeau@apache.org <mailto: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