Like I said before, I would rather have been the guy sending you hate emails for making me switch at the time I upgraded because then we could have dealt with the problem on our own terms--rather than getting burned by an enourmous fire in our live production environment.

I understand "deprecated" to mean that a different design choice has been made, not that something is buggy and is going to deadlock the system.

If you don't want to remove the buggy code, please at least put a warning in config.xml that mordred under certain normal circumstances will deadlock.

Nathan

Serge Knystautas wrote:

Nathan Cheng wrote:

Because it was not "replaced"--it is still distributed with James 2.2.0. On top of that, the config.xml distributed with James 2.2.0 does not say that it is buggy, but rather that it is simply "deprecated in favor of". On top of that, Noel is still using it. And on top of that, it just bit me really hard.

So I wish that you had indeed "replaced" this broken code 14 months ago. By all means, please do it now.


We tell new users what to do (say it is deprecated), we still leave it there for users who want to go against our advice (Noel).

I'm sorry this hit you so severely, but everytime there's a bug, I cannot simply delete the code that had problems.

<attempted-humor>
Or rather, I would get /different/ hate emails from users saying, "My configuration worked perfectly with version x.y. I just wasted 2 days because of some forced change when I upgraded to version x.z. Every time one of you developers get some whim, I'm stuck reconfiguring my server that was working perfectly!!!"
</attempted-humor>



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to