[PROPOSAL] default exclusion of unstable blocks on release

[Torsten Curdt <tc...@vafer.org>]

As brought up on the javaflow-block discussion
it seems like the warning header on build time
is not good enough to give the right perception
of the status of unstable blocks.

So on one hand default *inclusion* makes sure
the code at least compiles and helps to keep
everything running smoothly.

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

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.

Everyone using HEAD should know how to enable
and disable blocks and also should be aware of
it's status.

WDYT?
--
Torsten

Re: [PROPOSAL] default exclusion of unstable blocks on release

[Joerg Heinicke <jo...@gmx.de>]

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