« Return to Thread: Tentative Roadmap
Re: Tentative Roadmap
by Alexandru Popescu ☀
::
Rate this Message:
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
> 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
« Return to Thread: Tentative Roadmap
| Free embeddable forum powered by Nabble | Forum Help |
