Re: Tentative Roadmap

>
> 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
>
>