commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Wed, 06 Feb 2008 11:00:26 GMT
From: Henri Yandell <>
On Feb 5, 2008 5:27 AM, Stephen Colebourne
 <> 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
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message