---- Stephen Colebourne <[EMAIL PROTECTED]> schrieb: > Deprecation is useful when a method has been > implemented incorrectly, and we want to push users > to a replacement, or for similar issues. Removing deprecated > classes/methods should be considered in a major version change, > but even there we should question what the gain is. Having a > 'nice and clean' no deprecations API release isn't sufficient a > reason. We must always put the convenience of our users ahead of > our natural refactoring and coding instincts.
+1 If a deprecated method is blocking significant improvement of the product, then ok remove it. But just to "clean up" is not really a good enough excuse. > The problem is that there is no practical solution to a jar > hell situation. Thus, it is our absolute responsibility to > do everything in our power to avoid us being the cause of it. Over the last two weeks I've been working on embedding jspwiki into a locally developed application. Now jspwiki is compiled against Lucene 1.4.3, but the app already uses Lucene 2.3.0. And yep, they are incompatible (slightly, but enough). Fortunately jspwiki's search functionality is "pluggable" so by rewriting one jspwiki class I could make things work. But if the problem library had been more deeply embedded into the two systems I don't know what I could possibly have done. Of course if the new release was org.apache.lucene2, then there would be no problem. Compatibility is important. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
