<snip/>
So, I'm in favour of deprecating this in 2.1 now and removing it in 2.2.
While I'm more than ok with simplifying stuff, we have to take great care of backwards incompatible changes.
Our version-naming scheme "x.y.z" states that compatibility should be ensured between different "y" versions. This has not been exactly the case between 2.0 and 2.1, and I fear that the more radical changes that occur between 2.1 and 2.2 will lead to more incompatibilities.
So the question is: aren't we moving towards a 3.0 release?
Or shouldn't we make more effort at defining Cocoon's public and private APIs? I made a proposal a while a go for this, based on javadoc attributes, but never investigated it further.
Should we make this a high priority task, so that we can distinguish what we consider to be Cocoon's internal from the officially supported API?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
