cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Date Tue, 13 Dec 2005 19:56:25 GMT
Jorg Heymans skrev:
> 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.

Wait until after ApacheCon and go ahead after that.

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


With 2.2 we have separate release cycles for the different blocks. So if 
no one is interested enough to do a release of a block it will not be 


View raw message