Re: Tentative Roadmap

> I 100% agree with you. Performance is weakest point of Groovy runtime.
> Even with improvements we did in 1.5. As we said many times we can't
> resolve it without full redesign of MOP. So, it should be priority
> number one.
>
> On Dec 17, 2007 12:25 PM, Alexandru Popescu ☀
> <the.mindstorm.mailinglist@...> wrote:
> >
>
> > On Dec 17, 2007 1:50 AM, Guillaume Laforge <glaforge@...> wrote:
> > > Dear Groovy developers,
> > >
> > > Now that we have released 1.5, it is time to think about the future of
> > > Groovy, by discussing its roadmap.
> > >
> > > After some discussions at GDC#4 (
> > > http://docs.codehaus.org/display/GroovyJSR/GDC4+Discussions), on the lists,
> > > and elsewhere, we've listed possible improvements and new features.
> > >
> > > Jochen and myself compiled a tentative roadmap this weekend, taking these
> > > ideas into account and trying to lay them out across potential release
> > > numbers.
> > >
> > > This is a tentative roadmap.
> > > Certain features can be discussed, whether we do want them or not.
> > > And there's room for moving features from one to another release.
> > > New ideas missing can also be introduced.
> > > So it's still pretty open at the moment.
> > >
> > > Note that the roadmap can change across the course of time according to the
> > > progress (or lack thereof) we make on the GEPs (Groovy Extension Proposals).
> > > It is not set in stone today, even after our upcoming discussions. The GEPs
> > > will drive us through the releases.
> > > It is very important that we try to clearly define what we want to do in the
> > > coming releases, and not just commit blindly any cool hacks :-)
> > > We need to have crystal clear scope and semantics for all major features.
> > >
> > > First of all, the basic idea: instead of one huge release a year with
> > > several betas and RCs, it'd be great if we could make more frequent releases
> > > (with a few betas and RCs) every two or three months or so, but containing a
> > > lower number of major features. So ideally, we could release 1.6 / 1.x
> > > throughout the year, with a bigger 2.0 at then end of next year with a
> > > reworked MOP system.
> > >
> > > There are three main kind of releases:
> > > - 1.5.x will provide some patches to the 1.5 final release
> > > - 1.6 / 1.x will introduce a few major features at each release depending on
> > > the completeness of the GEPs
> > > - and 2.0 will focus on the reworked MetaClass runtime system and will be
> > > worked on in parallel to the other 1.x releases.
> > >
> > > Ideally, we should try to release 1.5.1 next week, before Christmas, with
> > > the current fixes for the Ant builder, the dead lock in the class loader.
> > > And probably a 1.5.2 when we find the concurrency issue we have on parallel
> > > environments.
> > >
> > > Without further ado, here's the proposed Roadmap.
> > > The GEPs will be there for defining the exact scope of the major features by
> > > giving some finer-grained details of the content of the upcoming releases.
> > > I'll publish this roadmap on the JSR wiki.
> > >
> > > Groovy Roadmap
> > > Groovy 1.5.1
> > >
> > > Bug fix release
> > > Deadlock in GroovyClassLoader
> > > Problem with Ant tasks
> > > Groovy 1.5.2
> > > Bug fix release
> > > Concurrency issues (unless it's fixed in 1.5.1)
> > > Groovy 1.6
> > >
> > > Based on JDK 1.5 with Retro* version available for JDK 1.4
> > > Make sure we can run the unit tests with the retro-weaved jar to ensure
> > > compatibility
> > >
> > > Annotation definition in Groovy
> > > Currently, annotations can't be defined in Groovy, only used
> > >
> > > Multiple assignment
> > > GEP
> > > Define the exact scope of multiple assignment by revisiting the existing GEP
> > > page
> > >
> > > Groovy 1.7
> > >
> > > Upgrade to ASM 3
> > > if necessary or deemed useful (more efficient bytecode?)
> > >
> > > Groovy incremental compiler
> > > Especially useful for the Eclipse plugin
> > >
> > > AST transformations
> > > GEP
> > > reuse of annotations or not
> > > exact scope of those transformations
> > > pluggable AST transformations for advanced DSL or integration cases
> > >
> > > Groovy 1.8
> > >
> > > Nested Classes & Anonymous Inner Classes
> > > GEP
> > > The exact semantics with relationship to the MOP should be properly defined
> > > through a GEP
> > >
> > > Groovy 1.9
> > > Upgrade to Antlr 3
> > > We'll be able to use the tooling support accompanying Antlr 3
> > > Concurrency features
> > > GEP
> > >
> > >
> > > Define what coverage we'd like to bring
> > > Rollback the iterator features to properly discuss them first
> > >
> > > Work on this theme first as a module, and if deemed right, we can bring it
> > > back to groovy-core
> > >
> > > Groovy 2.0
> > >
> > > New MetaClass system
> > > Benchmark test suites to track progress of performance across releases
> > >
> > > GEP
> > > defining the scope of changes
> > > describing the new system
> > > proposals of a more homogeneous system
> > >
> > > homogenize categories, EMCs, custom metaclasses
> > > homogenize the configuration / declaration / convetions
> > > have per-thread / scoped EMCs (like categories)
> > >
> > > per-module/library metaclasses
> > >
> > >
> > >
> > > --
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > G2One, Inc. Vice-President Technology
> > > http://www.g2one.com
> > >
> >
> > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > detailed roadmap.
> >
> > Now, I would like to add my opinion about it (opinion that might not
> > match exactly the above plan).
> >
> > I do consider that the Groovy language has become "enough" feature
> > rich. IMO, the most important aspects for the future of the language
> > are now more in terms of usability. I don't think I can come out with
> > a nice proposal as you did, but my suggestion would be that the work
> > should focus on the following directions:
> >
> > 1/ fixing bugs related to the 1.5 major release. This will probably
> > result in a couple more minor releases.
> >
> > 2/ focus on the performance. As discussed at GDC this mostly means
> > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > would definitely see the whole energy of the Groovy people going this
> > direction only for the next period.
> >
> > Probably the only "new" feature that I see as belonging to "usability"
> > is the multi-assignment, but this is just a nice to have one, so it
> > shouldn't focus on it right away (or at least I wouldn't consider it
> > as a strict goal for the next immediate period).
> >
> > Hope you don't mind expressing my thoughts here,
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>