From: Henri Yandell <[EMAIL PROTECTED]> On Feb 5, 2008 5:27 AM, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > The practical impact of a new package is small to users that use commons-io directly - a quick organize imports in an IDE. The impact of NOT doing this would be jar hell, if your application relied on another open source library that still used v1.4.
> Then there should never be a 2.0; it should remain as 1.5, 1.6, 1.12 etc. > 2.0 is semantically meaningless. A change of package name and a change of required Java version is certainly enough to warrant a new major version IMHO. IMO, Java 5+ is almost a different language to pre Java 5. The fact that the Java community has taken ages to move up is a sign of this. > I buy your argument for huge changes, ie) collections-generics is very > much a different product. I don't buy it for small API changes and > removal of deprecation. Your argument would imply that we should never > deprecate (as we're never going to actually remove it) and that we > never increase a major version except for PR reasons. 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. > If IO 2.0 is hugely different so as to be a new product, then sure. If > it's practically the same with minor API breakage, then I still don't > see the need to cause pain to many for the few who think they can > magically upgrade major versions in production. Sure we'll get > cross-dependency problems, but that just implies to me that we > shouldn't be doing major upgrades all the time. 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. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
