commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Tue, 05 Feb 2008 13:27:54 GMT
> On Feb 4, 2008 8:47 PM, Niall Pemberton <niall.pemberton@gmail.com>  
>> From memory the preference was to move to a new package name  - how
>> about "org.apache.commons.io2"?
To avoid confusion with version numbers, we could choose [io-two]:
 org.apache.commons.io-two


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.


>> Are there any objections to me creating an IO 1.4 branch from the
>> current trunk and then starting work on IO 2.0 in the trunk.
> Any need to make the branch?
> ie) Wait until you need it; as long as you have a tag of the latest
> release you can always branch from that.

My gut feeling is that TRUNK should be for v2.0. The alternative of a separate commons component
for [io-two] seems overkill.


From: Torsten Curdt <tcurdt@apache.org>
> I think it would much more consistent to do it across the board.

Each component will have to make their own decisions, but I suspect [io]/[lang]/[collections]
will help guide the way.


Stephen



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message