Niclas Hedhman wrote:
On Friday 03 December 2004 23:22, Sylvain Wallez wrote:
<snip />
Well put.
Maybe we should be less shy to deprecate things. But the problem is that
deprecation means future deletion, which also scares people as it
doesn't give the image of something stable. Maybe some "mainstream-ness"
classification would allow people new to Cocoon to more easily find
their way into the system, while still giving the necessary code and
documentation to people having "legacy" Cocoon applications.
Yes that sounds very reasonable. <warning type="analogy" >
"Not recommended for new designs" it is called in the electronics industry. That means that the part is manufactured, but there are better and cheaper ones around, and by natural selection the part will be of no demand in long enough time. When the demand is low enough, a final production run is made (deprecation) and all customers are informed, and can order any quantity for their own stock keeping for spare parts or whatever.
</warning>
This is a very good analogy.
So, back to Cocoon; If you have a system where you can mark "not recommended for new designs", and then at the point of deprecation that 'part' could moved out of the standard dist, docs, discussion sphere, you are better set for a graceful end-of-life.
I totally agree with you.
Mind you, these are non-urgent stuff, and I guess really noone's itch.
Well, this is non-urgent as old things don't need work as bug fixes or new feature do, but the fact that we are discussing here shows that there is an itch.
Now scratching may not be that complicated: let's just add a new attribute managed by the SitemapTask to automatically indicate the "freshness" status of a component in the docs. That can be a first step, the next one being writing overview docs explaining best practices.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
