cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Growing, overall consistency and deprecation (was Re: Janino, an embedded java compiler)
Date Fri, 03 Dec 2004 17:50:17 GMT
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>
> 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.
> Mind you, these are non-urgent stuff, and I guess really noone's itch.


Cocoon is what it is because we are not afraid of changing our mind and 
to collectively discuss things on the list and we don't act before we 
have consensus.

Sure, FS creeps in (and I'm fighting it against taglibs, the ultimate FS 
evil in my eyes, even Jelly's author moved away from it ashamed) but 
that's why we have discussions.

We lack documentation and best practices and efforts are underway to 
solidify those (our documentation is a lot better than it used to be).

In short: you should not obtain your knowledge from reading the dev- 
list and we are solidifying many solutions into a recommended one, not 
adding more things.

And don't worry, my FS alarms might be slower to react these days (do to 
the fact that I have a day job now) but are never turned off ;-)


View raw message