---- Niall Pemberton <[EMAIL PROTECTED]> schrieb: > On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > > ---- 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. > > I don't mind the deprecations staying for IO 2.x - just thought that > if there was going to be a package rename for JDK 1.5, then may as > well clean up the deprecations as well. If, because of generic erasure > IO 2.x isn't incompatible (except for the requirement for a higher JDK > version) then how about retaining the current package name?
*If* the package name changes, then the deprecated methods should definitely go, as there is no way removing them can break existing users and lead to jar hell. Regarding a new java5-enabled io that is backwards-compatible: well, if the existing API is sound, and can be adequately genericised without breaking backwards compatibility, then keeping the old package-name seems sensible. Adding new methods is not a problem, as that won't break existing users. Only if the existing methods need to be refactored would a package-name change make sense. Alternatively, where existing apis cannot be made generic without breaking existing users, maybe the new methods could be added within a different package of the existing commons.io library, leaving the old ones alone? Then there is still one jar that everyone can use. Yes there would be a bit of duplicated code in it, but that's still easier to manage than maintaining 1.x and 2.x branches. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
