Re: [groovy-dev] Tentative Roadmap

Looks great, specially the incremental compiler as we would definitely use it
at work too.
I wonder where does handling private access fall? as well as possibly
allowing < <= => > to be overridden independently of <=>

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

--

-- 
View this message in context: http://www.nabble.com/Tentative-Roadmap-tp14368039p14368673.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] 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

Re: [groovy-dev] Tentative Roadmap

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

Are any of these milestones going to introduce breaking changes? I'd imagine
the new MetaClass work would do so.

John Wilson

--

-- 
View this message in context: http://www.nabble.com/Tentative-Roadmap-tp14368039p14370213.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] Tentative Roadmap