cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Date Tue, 13 Dec 2005 08:51:10 GMT

Carsten Ziegeler wrote:

> I strongly suggest that we start creating roadmaps. This also would make
> the development of Cocoon for users much more transparent. Currently I
> have only two points which I really think have to be finished for 2.2:
> the build/deployment stuff and making the current blocks available
> separatly/providing an own versioning for them. So as soon as the m2
> integration works, we can polish 2.2 a little bit and then release the
> core and each blocks as 2.2 and from the on develop the core and the
> blocks independently and release them independently. Everything else can
> follow later on.

I've been working a bit more behind the scenes lately to get excalibur 
to behave properly under m2. I am currently switching the flat layout in 
the whiteboard to the new excalibur poms to see how they behave and do 
first tests. Once i'm done there i can focus more on the deployment 
integration again.

What about the repository reorganisation I suggested in [1]? Given a 
more flat and m2 consistent layout, i can *easily* put it under 
continuum control like i did with excalibur [2]. Note that we wouldn't 
use continuum's CI features as such, but merely use it as an automated 
snapshot release tool. It would thus replace my cronned shell script for 
doing snapshot releases and make it possible to force a snapshot release 
at the click of a button.

The only thing about the repo reorg is that i don't want to stall 
current development momentum, but frankly i don't really see a way not 
to - at least for a few days.

Also: are we carrying forward all blocks to 2.2 or is this the time 
where we ditch the obscure, rarely used and "blocks that don't really 
deserve to be a block" blocks? I'ld say we choose the 10 most often used 
and well known blocks and let the users voice their concern about those 
blocks we aren't taking forward. If enough noise, we can then still 
decide to support these blocks ourselves again or even offer it to 
dedicated users to maintain themselves.



View raw message