[groovy-dev] Towards 1.8-beta-4 on Friday

Hi all,

We're going to release 1.8-beta-4 on Friday (a joint release with 1.7.7).

If you have some things in the works, please raise your hand, and we can see if we can integrate that in time for the release.

Beta-4 should be the last beta release for 1.8, with the idea of switching to Release Candidate mode (and hence feature freeze, with only key fixes to be committed).

We'll create a 1.8 branch after the beta, and trunk will become Groovy 1.9.

Keep on groovying

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

On Tue, 2011-02-01 at 14:15 +0100, Guillaume Laforge wrote:
[ . . . ]
> 
> We're going to release 1.8-beta-4 on Friday (a joint release with
> 1.7.7).
> If you have some things in the works, please raise your hand, and we
> can see if we can integrate that in time for the release.

Grails needs a Gant to be released with the Groovy 1.8.0 release, so I
am raising my hand for a co-release cycle.

> Beta-4 should be the last beta release for 1.8, with the idea of
> switching to Release Candidate mode (and hence feature freeze, with
> only key fixes to be committed).

Russel being (tediously) repetitive, to pre-empt the usual argument:

Once release candidate mode is entered, there should be nothing
committed to the release branch at all unless it is critical to the
release to fix a blocking or majorly critical bug.   The final release
artefacts should be identical to the final release candidate -- just a
name change.  Once the release is made the branch can be opened for bug
fixes.  Once 1.8.0 is released, only bug fixes should be applied leading
to 1.8.1, 1.8.2, etc., no development should happen on the maintenance
branch, all development should be on the 1.9.0-snapshot branch.

> We'll create a 1.8 branch after the beta, and trunk will become Groovy
> 1.9.

I wonder if there should be some access control applied to the
maintenance branches so as to ensure only bug fixes are applied?

> Keep on groovying 

GPars rocks. 

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

I think we should finish investigation with huge memory leak Marc has
in grails before going to 1.7.7

Regarding next beta 1.8.x I believe (and would love to hear opinions
of other committers) that before doing that we need to measure/analize
performance of Jochen's refactorings

On Tue, Feb 1, 2011 at 3:15 PM, Guillaume Laforge <glaforge@...> wrote:
> Hi all,
> We're going to release 1.8-beta-4 on Friday (a joint release with 1.7.7).
> If you have some things in the works, please raise your hand, and we can see
> if we can integrate that in time for the release.
> Beta-4 should be the last beta release for 1.8, with the idea of switching
> to Release Candidate mode (and hence feature freeze, with only key fixes to
> be committed).
> We'll create a 1.8 branch after the beta, and trunk will become Groovy 1.9.
>
> Keep on groovying 
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

> Regarding next beta 1.8.x I believe (and would love to hear opinions
> of other committers) that before doing that we need to measure/analize
> performance of Jochen's refactorings

I tend to agree that the Groovy team's performance statistics need to show a real performance improvement
before we tell people to download the beta. We're asking people to beta test for us, and without being sure
that the performance is better there is nothing to really test (besides all the other features, that is). 

--
Hamlet D'Arcy
hamlet.darcy@...

----- Original Message -----
> I think we should finish investigation with huge memory leak Marc has
> in grails before going to 1.7.7
> 
> Regarding next beta 1.8.x I believe (and would love to hear opinions
> of other committers) that before doing that we need to measure/analize
> performance of Jochen's refactorings
> 
> On Tue, Feb 1, 2011 at 3:15 PM, Guillaume Laforge <glaforge@...>
> wrote:
> > Hi all,
> > We're going to release 1.8-beta-4 on Friday (a joint release with
> > 1.7.7).
> > If you have some things in the works, please raise your hand, and we
> > can see
> > if we can integrate that in time for the release.
> > Beta-4 should be the last beta release for 1.8, with the idea of
> > switching
> > to Release Candidate mode (and hence feature freeze, with only key
> > fixes to
> > be committed).
> > We'll create a 1.8 branch after the beta, and trunk will become
> > Groovy 1.9.
> >
> > Keep on groovying 
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > Head of Groovy Development at SpringSource
> > http://www.springsource.com/g2one
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

Am 01.02.2011 14:40, schrieb Russel Winder:
[...]
> Once release candidate mode is entered, there should be nothing
> committed to the release branch at all unless it is critical to the
> release to fix a blocking or majorly critical bug.   The final release
> artefacts should be identical to the final release candidate -- just a
> name change.  Once the release is made the branch can be opened for bug
> fixes.  Once 1.8.0 is released, only bug fixes should be applied leading
> to 1.8.1, 1.8.2, etc., no development should happen on the maintenance
> branch, all development should be on the 1.9.0-snapshot branch.

the plan is the following... after the beta we make a 1.8.1 branch and 
an 1.8 RC branch. Trunk becomes 1.9. Only really critical things go to 
1.8 RC, normal 1.8 work can continue in the 1.8.1 and 1.9 branches. We 
plan to RCs, in the hope of not needing them really. Since people are 
usually to lazy to merge to other branches anyway, there should be no 
problem with an RC branch ;)

bye Jochen

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

Am 01.02.2011 14:50, schrieb Alex Tkachman:
> I think we should finish investigation with huge memory leak Marc has
> in grails before going to 1.7.7

I gave Marc a new groovy-all version with what we were talking about 
yesterday. The huge memory leak is only one because of the faulty GC. I 
am at least not the only one seeing it as a bug. I hope with the action 
we took the memory leak is done with. The only other thing we could do 
after that is nulling out references really. The next version of Grails 
plans on using 1.7.6, not 1.7.7 and we can make a fast release for 1.7.8 
if really needed.

> Regarding next beta 1.8.x I believe (and would love to hear opinions
> of other committers) that before doing that we need to measure/analize
> performance of Jochen's refactorings

What exactly do you mean? Run some programs and see what gets faster and 
what slower? It would be good to analyze what cases really get slower, 
since then I could avoid the fast path (that is no fast path then) for 
these situations. But the performance improvements enabled are atm only 
int operations, method calls on this or static method calls in which the 
target class is the same as the class the call is made from and the 
arguments obey certain constraints - and int array getAt and setAt 
operations. I think the method call code still needs one or the 
improvement here and there, not too sure.

I would also like to test things like an empty loop, that gets optimized 
away by JIT at some point, but I am not yet sure about how to really 
test that. I can see it atm only through a non linear time increase for 
the loop or by the JIT telling me, only I don't know how it would tell me.

And of course there are several things that are not optimal.. for 
example a category disabling all fast paths. A disabled fastpath is 
performance wise worse than if compiled without the fast path at all, 
but only slightly.

Also many optimizations I have in mind are still missing... some for 
Closures, but more important for micro benchmarking is doubles and other 
things.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

Am 01.02.2011 15:03, schrieb Hamlet DArcy:
>> Regarding next beta 1.8.x I believe (and would love to hear
>> opinions of other committers) that before doing that we need to
>> measure/analize performance of Jochen's refactorings
>
> I tend to agree that the Groovy team's performance statistics need to
> show a real performance improvement before we tell people to download
> the beta. We're asking people to beta test for us, and without being
> sure that the performance is better there is nothing to really test
> (besides all the other features, that is).

oh, you think the other improvements are not really worth it?

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[groovy-dev] Re: Towards 1.8-beta-4 on Friday

Hi Jochen,
can we expect more performance improvements to be made in the 1.8 release as
mentioned in:
GROOVY-3951  Groovy 1.8 runtime performance improvements 
GROOVY-3950  Groovy 1.8 compiler performance improvements  

We are already very happy with Groovy, but we are keen on improvements in
the performance area. We were looking forward to the 1.8 release since
performance improvements is mentioned in the 1.8 roadmap, so is this still
something which is scheduled or will this be moved to a future release?

kind regards,
Christiaan
--

-- 
View this message in context: http://groovy.329449.n5.nabble.com/Towards-1-8-beta-4-on-Friday-tp3366173p3366406.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday

> oh, you think the other improvements are not really worth it?

I think the performance improvements are a big deal. The other features are contained, and do not spread
across Groovy the way this feature does. It doesn't get more 'core' than optimizing operations. If there
is a problem in  <at> WithReadLock then people can easily not use it. If there is a problem with int
optimizations then it's very hard to word around that. Because of this added risk, I feel the int
optimization is the most important thing to test, and it is the feature I'm most excited to see the results
of. You know better than me, but it seems that some code will be faster and some code will be slower, but we're
not exactly sure what the overall metrics are going to be (Perhaps the metrics exist and I missed that
thread). 

So we have a big, important, pervasive feature that needs testing. Is it mature enough to go to beta? Only you
can answer that question. My point is that your work is on different scale than a few contained AST
transformations. We should take this next beta more seriously than the previous one.

--
Hamlet D'Arcy
hamlet.darcy@...

----- Original Message -----
> Am 01.02.2011 15:03, schrieb Hamlet DArcy:
> >> Regarding next beta 1.8.x I believe (and would love to hear
> >> opinions of other committers) that before doing that we need to
> >> measure/analize performance of Jochen's refactorings
> >
> > I tend to agree that the Groovy team's performance statistics need
> > to
> > show a real performance improvement before we tell people to
> > download
> > the beta. We're asking people to beta test for us, and without being
> > sure that the performance is better there is nothing to really test
> > (besides all the other features, that is).
> 
> oh, you think the other improvements are not really worth it?
> 
> bye blackdrag
> 
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead
> http://blackdragsview.blogspot.com/
> For Groovy programming sources visit http://groovy.codehaus.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] Towards 1.8-beta-4 on Friday