cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [PROPOSAL] default exclusion of unstable blocks on release
Date Tue, 30 Mar 2004 09:36:18 GMT
On 30.03.2004 11:27, Torsten Curdt wrote:

> On the other hand this give the perception
> that the unstable stuff is already ready
> for for production.

Might be true.

> So first I though disabling all unstable blocks
> would be the best choice. But what about this:
> 
> In the HEAD branch we enable all the unstable
> blocks by default and on a release we disable
> all of them.

Another good proposal.

To have it in the right thread I add my comments about the block 
selection handling here too as the above and mine are orthogonal:

IMO having blocks disabled is not a problem. But the way re-enabling 
them is. It's no longer possible to tell the user "copy 
blocks.properties to local.blocks.properties and edit this one". I 
already had this issue when only including woody block after deprecation.

So when doing it - what it is a good thing - we have to change the build 
process in relation to blocks selection. Isn't it possible to switch to 
include.block.{blockname}={true|false} syntax as this property is not 
used directly in blocks-build.xml, but mapped to a property 
unless.exclude.block.{blockname} at the moment:

<condition property="unless.exclude.block.fop">
   <istrue value="${exclude.block.fop}"/>
</condition>

Doing the mapping in another should not be impossible, allows us to use 
the more intuitive notation proposed above and removes the need for 
adding blocks.properties at all.

Joerg

Mime
View raw message