cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
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 to 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}"/>

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


View raw message