> On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>  
>> 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 <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to