commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Wed, 06 Feb 2008 04:02:23 GMT
On Feb 5, 2008 5:27 AM, Stephen Colebourne <> wrote:

> On 05.02.2008, at 06:44, Henri Yandell wrote:
> > For Collections it makes sense as there's a big API change planned.
> > For the others, I think they should charge in and see what kind of
>  API
> > changes are required. If we're talking small ones, then I'd prefer
>  not
> > to. I continue to not think that the next major version of a jar has
> > to kill itself over backwards compatibility (ie: what's the point of
>  a
> > major version).
> Because it is absolutely essential that we allow compatibility with the older release.
> Specifically, it is a requirement that if there are any binary or source incompatible
changes, then an application must be able to run with both the old and new jar files (v1.4
and v2.0). The only practical way in Java today is to have the two incompatible versions in
two separate packages.
> 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.

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.

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.

My tuppence anyway.


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

View raw message