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
