You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2016/10/19 14:32:25 UTC
getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Hi,
I�dd like to collect here a list of things we have to do to get the next
2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see
the following we should integrate the new parser (could be done for
2.4.x as well), but otherwise I think we should go forward here as well.
Any objections?
bye Jochen
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Cédric Champeau <ce...@gmail.com>.
If we could get a fix for https://issues.apache.org/jira/browse/GROOVY-7966,
it would help Gradle, because it prevents our caching from working without
a hack (basically sorting files, which has a performance cost).
2016-10-19 16:32 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
> Hi,
>
> I´dd like to collect here a list of things we have to do to get the next
> 2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
> 2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see the
> following we should integrate the new parser (could be done for 2.4.x as
> well), but otherwise I think we should go forward here as well.
>
> Any objections?
>
> bye Jochen
>
>
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Guillaume Laforge <gl...@gmail.com>.
Mario, did you try the WIP by Daniel Sun, to provide feedback, see how it
works on your code base?
That's also a way to help and assess how far we are from having the new
parser ready, if you've got a bit of time to try it out.
On Wed, Oct 19, 2016 at 6:11 PM, Mario Garcia <ma...@gmail.com> wrote:
> +1 for releasing 2.4.8 asap
>
> Does anyone have any idea of how long is going to take the new parser to
> be ready ? It's a matter of weeks, months, maybe days? I think that
> information would help to plan future releases.
>
> Mario
>
> On 19 Oct 2016 17:15, "Pascal Schumacher" <pa...@gmx.net>
> wrote:
>
>> +1 for releasing 2.4.8 as soon as possible. There are already 67 fixed
>> issues:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20G
>> ROOVY%20AND%20fixVersion%20%3D%202.4.8%20ORDER%20BY%20stat
>> us%20DESC%2C%20priority%20DESC
>>
>> Am 19.10.2016 um 16:32 schrieb Jochen Theodorou:
>>
>>> Hi,
>>>
>>> I´dd like to collect here a list of things we have to do to get the next
>>> 2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
>>> 2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see the
>>> following we should integrate the new parser (could be done for 2.4.x as
>>> well), but otherwise I think we should go forward here as well.
>>>
>>> Any objections?
>>>
>>> bye Jochen
>>>
>>>
>>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: getting in line for the releases of groovy 2.4.8 and
2.5.0-beta-1
Posted by daniel_sun <re...@hotmail.com>.
Hi Cédric,
If possible, how about providing the new parser via putting it in a
separate artifact(e.g. groovy-parser-x.x.x.jar). When Groovy developers want
to try the new parser, they can enable the switch(-Dgroovy.antlr4=true).
Before set the new parser as the default parser in the future release, we
can get many feedback and make the new parser better and better :)
Although there are 3 failing test cases related to macro, Sergei's
PR(https://github.com/apache/groovy/pull/443) can fix them. I wish the PR
could be reviewed and merged as soon as possible.
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/getting-in-line-for-the-releases-of-groovy-2-4-8-and-2-5-0-beta-1-tp5736209p5736226.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Jochen Theodorou <bl...@gmx.org>.
On 20.10.2016 10:31, C�dric Champeau wrote:
> I would much favor letting the 2.4 branch die (aka, release 2.4.8), then
> make 2.5-beta and final asap, and release regular 3.0 milestones.
I think that is too early to decide right now. Because right now we need
to release 2.4.8 and 2.5.0-beta-1. And I expect at least one last 2.4.9
after a 2.5.0 before we let the 2.4.x branch die
bye Jochen
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Cédric Champeau <ce...@gmail.com>.
I would much favor letting the 2.4 branch die (aka, release 2.4.8), then
make 2.5-beta and final asap, and release regular 3.0 milestones.
2016-10-20 10:29 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
> On 20.10.2016 09:28, Cédric Champeau wrote:
>
>> I don't think it's reasonable to put the new parser in 2.5. There are
>> too many grey areas: performance, backwards compatibility, dependencies,
>> upgrade to Java 8... Better ship 2.5, then work hard on 3.0, even if it
>> means delaying MOP2 to 4.0.
>>
>
> first of all it is a beta. Doing experimental stuff in a beta must be
> allowed. If we move the parser to 3.0 it will take ages before it gets
> really tested. A beta is also about finding the black holes in the grey
> areas and otherwise fill it with light. I don´t know if things changed
> since we are at apache, but the only more broadly user tested versions of
> groovy are released versions. Rarely somebody builds Groovy from source or
> uses an artifact from our ci server. Not on a regular base anyway and not
> to test new features.
>
> bye Jochen
>
>
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Jochen Theodorou <bl...@gmx.org>.
On 20.10.2016 09:28, C�dric Champeau wrote:
> I don't think it's reasonable to put the new parser in 2.5. There are
> too many grey areas: performance, backwards compatibility, dependencies,
> upgrade to Java 8... Better ship 2.5, then work hard on 3.0, even if it
> means delaying MOP2 to 4.0.
first of all it is a beta. Doing experimental stuff in a beta must be
allowed. If we move the parser to 3.0 it will take ages before it gets
really tested. A beta is also about finding the black holes in the grey
areas and otherwise fill it with light. I don�t know if things changed
since we are at apache, but the only more broadly user tested versions
of groovy are released versions. Rarely somebody builds Groovy from
source or uses an artifact from our ci server. Not on a regular base
anyway and not to test new features.
bye Jochen
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Cédric Champeau <ce...@gmail.com>.
I don't think it's reasonable to put the new parser in 2.5. There are too
many grey areas: performance, backwards compatibility, dependencies,
upgrade to Java 8... Better ship 2.5, then work hard on 3.0, even if it
means delaying MOP2 to 4.0.
2016-10-20 1:52 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
> On 19.10.2016 18:11, Mario Garcia wrote:
>
>> Does anyone have any idea of how long is going to take the new parser to
>> be ready ? It's a matter of weeks, months, maybe days? I think that
>> information would help to plan future releases.
>>
>
> I just made an experiment in which I moved the antlr2 parser in its own
> sub project and the java compilation in the main project is supposed to be
> done without the antlr part, by solely working on abstractions.
>
> Well, it turns out we have several dependencies on antlr classes in
> SourceUnit, GenericsUtils and Numbers, most possibly in more parts. If we
> want to be truly able to use only the new parser, then we need to clean
> these things up. Especially depending on antlr exceptions looks very wrong
> to me. But also this construct:
>
> AntlrParserPlugin plugin = new AntlrParserPlugin() {
>> @Override
>> public ModuleNode buildAST(final SourceUnit sourceUnit,
>> final ClassLoader classLoader, final Reduction cst) throws ParserException {
>> ref.set(makeTypeWithArguments(rn.getAST()));
>> return null;
>> }
>> };
>>
>
> which can be found in GenericsUtils, but also in
> MarkupTemplateTypeCheckingExtension.
>
> If we want to fix these, it surely is not a matter of a few days. We could
> do without fixing these and work on having them fixed for the next 2.5 beta
> release. Without fixing these the GroovyShell might get problems if you
> want to use any new syntax element.
>
> What do others here think?
>
> bye Jochen
>
>
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 18:11, Mario Garcia wrote:
> Does anyone have any idea of how long is going to take the new parser to
> be ready ? It's a matter of weeks, months, maybe days? I think that
> information would help to plan future releases.
I just made an experiment in which I moved the antlr2 parser in its own
sub project and the java compilation in the main project is supposed to
be done without the antlr part, by solely working on abstractions.
Well, it turns out we have several dependencies on antlr classes in
SourceUnit, GenericsUtils and Numbers, most possibly in more parts. If
we want to be truly able to use only the new parser, then we need to
clean these things up. Especially depending on antlr exceptions looks
very wrong to me. But also this construct:
> AntlrParserPlugin plugin = new AntlrParserPlugin() {
> @Override
> public ModuleNode buildAST(final SourceUnit sourceUnit, final ClassLoader classLoader, final Reduction cst) throws ParserException {
> ref.set(makeTypeWithArguments(rn.getAST()));
> return null;
> }
> };
which can be found in GenericsUtils, but also in
MarkupTemplateTypeCheckingExtension.
If we want to fix these, it surely is not a matter of a few days. We
could do without fixing these and work on having them fixed for the next
2.5 beta release. Without fixing these the GroovyShell might get
problems if you want to use any new syntax element.
What do others here think?
bye Jochen
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Mario Garcia <ma...@gmail.com>.
+1 for releasing 2.4.8 asap
Does anyone have any idea of how long is going to take the new parser to be
ready ? It's a matter of weeks, months, maybe days? I think that
information would help to plan future releases.
Mario
On 19 Oct 2016 17:15, "Pascal Schumacher" <pa...@gmx.net> wrote:
> +1 for releasing 2.4.8 as soon as possible. There are already 67 fixed
> issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 20GROOVY%20AND%20fixVersion%20%3D%202.4.8%20ORDER%20BY%
> 20status%20DESC%2C%20priority%20DESC
>
> Am 19.10.2016 um 16:32 schrieb Jochen Theodorou:
>
>> Hi,
>>
>> I´dd like to collect here a list of things we have to do to get the next
>> 2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
>> 2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see the
>> following we should integrate the new parser (could be done for 2.4.x as
>> well), but otherwise I think we should go forward here as well.
>>
>> Any objections?
>>
>> bye Jochen
>>
>>
>
Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1
Posted by Pascal Schumacher <pa...@gmx.net>.
+1 for releasing 2.4.8 as soon as possible. There are already 67 fixed
issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20GROOVY%20AND%20fixVersion%20%3D%202.4.8%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC
Am 19.10.2016 um 16:32 schrieb Jochen Theodorou:
> Hi,
>
> I�dd like to collect here a list of things we have to do to get the
> next 2.4 and the first beta of 2.5.0 out. I do not know of any
> criticals for 2.4.x, so afaik it is ready for release any time now.
> For 2.5.0 I see the following we should integrate the new parser
> (could be done for 2.4.x as well), but otherwise I think we should go
> forward here as well.
>
> Any objections?
>
> bye Jochen
>