cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: on better release and version management
Date Fri, 19 Sep 2003 21:09:32 GMT

On Friday, Sep 19, 2003, at 15:54 Europe/Rome, Geoff Howard wrote:

> Hmmm... I've been assuming that the way a block actually gets coded 
> may need to change in order to interact with other real blocks, etc.  
> If this is not the case, then the whole issue of back-compatibility of 
> blocks goes away and keeping them in 2.1 is fine.

No. I took great care in designing the system so that it could work 
with existing blocks and incrementally adjust to the new features that 
the infrastructure provide.

it is true, however, that once a block starts depending on another 
block, it can no longer be considered a 'fake block' as the cocoon 2.1 
system is not designed to handle subdependencies (batik and fop, for 
> 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.


View raw message