We should get more specific on APIs here and what the problem is. If an algorithm changes, this is the same problem we have with a new version of any project. Either it's a bug fix and it is ok to change the behavior or it is not a bug fix and you need to decide if the behavior must be backward compatible. If it must be, then you need a new method name. Or a new class I suppose for pluggable classes. This can be dealt with on a case by case basis and is a separate discussion IMO.
The major differences in API I see is with generics, when we have today a class with possibly all of: 1) void fooArr(Foo[]); 2) void fooList(List listOfFoos); 3) Bar[] barArr(Bar[]); 4) List barList(List listOfBars); we want tomorrow, to replace 4) withy: 2) void fooList(List<Foo> listOfFoos); 4) List<Bar> barList(List<Bar> listOfBars); The question is: *What is the policy WRT 1, and 3?* a) Keep the APIs as is. b) Deprecate c) Remove Changing call sites from arrays to list is easy and mechanical but can be an extensive change. So I would start io2 with a) or b) at worst. Thank you, Gary > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of James Carman > Sent: Friday, February 08, 2008 7:24 AM > To: Jakarta Commons Developers List > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5 > > On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Feb 8, 2008 3:49 PM, James Carman <[EMAIL PROTECTED]> 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? > > > > No. I'd keep everything in o.a.c.io. > > > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to > > be changed extensively to match "Java 5 style", then I'd name the > > modified version o.a.c.io.SomeClass2 (or something better if > > possible). > > > > I don't know about that. Then, we could potentially have classes like > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it > wouldn't be as easy to upgrade to a new version. If it were done the > other way, folks could just do a find/replace on the package name in > their code and be done. > > On the other hand, it does allow you to introduce new incompatible > logic without requiring a new major release. Hopefully folks wouldn't > abuse that. > > > > I assume such cases to be the exception rather than the rule, so I > > don't see the point in renaming the entire package. > > > > Java 5 is just an enabler of new features (generics, etc.), it doesn't > > magically make existing APIs obsolete. Sure, you probably want to > > adjust collection types, but that's just like any other API change > > request. > > > > 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]
