I agree with James here. Spanning across packages makes this whole
thing overly complex. IMO we should keep it easy and consistent.
org.apache.commons.io = 1.x
org.apache.commons.io2 = 2.x
...
I think we are a little too afraid to maintain a second branch here.
I know we are few people. But if we switch to 2.x and move 1.x to
bugfix mode only. Upgrading to 2.x should not be that bad. For some
maybe not even more than a organize imports. No one is forced to
upgrade. So I don't really see the point of making our life harder
than it is.
cheers
--
Torsten
On 08.02.2008, at 14:49, James Carman wrote:
So, you are suggesting having part of a release in the o.a.c.io
package and the other part in the o.a.c.io2? It seems rather
inconsistent, but I guess it would work. Isn't that going to get
ugly with 3.x and 4.x releases adding to the mix?
On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On Feb 6, 2008 1:51 PM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
So the changes are pretty minimal for IO - question is are these
incompatible changes with generics being erased? If not then perhaps
we can do this without breaking anything.
+1 If there are cases where we can't avoid breaking backwards
compatibility, then let's use the name2 pattern on individual classes
or interfaces instead of the entire o.a.c.io package. There are large
parts of Commons IO that don't need to change when upgrading to
Java 5
and I don't see why a client that only uses those parts should be
affected in any way by the upgrade.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
