cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
Subject Re: on better release and version management
Date Sat, 20 Sep 2003 23:40:44 GMT
Stefano Mazzocchi wrote:
> 
>> OTOH if it is the case, then we're back to needing an uninhibited way 
>> to experiment with them, and the block.xml and the whole block content 
>> may need to be duplicated in 2.2 until cocoon-blocks is worked out.
> 
> yes. if the fop block, for example, requires dependencies on batik, it 
> cannot behave the same as a fake block and a real one. it has to move.
> 
>> But if we agree that any blocks in 2.2 will be kicked out later either 
>> to find a home at cocoon-blocks or elsewhere our hands still will be 
>> free.
> 
> Yes, I think this is a good compromise:
> 
> 1) keep blocks that don't have subdependencies on cocoon-2.1
> 
> 2) move blocks that have dependencies in cocoon-2.2
> 
> 3) when the block architecture is finished, design the procedures on how 
> blocks are
> 
>  - submitted
>  - accepted
>  - developped
>  - released
>  - frozen
> 
> i expect this to be a can of community worms and personal interests, so 
> i don't want to tacle this until we have something that works in place.

IMO this is difficult to maintain. If someone wants to look on the code 
base of a block he has to search for its dependencies first or search 
for the code at different places. Can't we extract the blocks from 2.1 
"as they are" at the moment and move them to cocoon-blocks module, so 
that they are collected at one place. Is the above proposal only because 
of community issues? What prevents us from doing the move to 
cocoon-blocks as first step?

Joerg


Mime
View raw message