On Thu, 2004-05-13 at 11:46, David Graham wrote: > --- Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > From: "David Graham" <[EMAIL PROTECTED]> > > > If I understand correctly, incompatible changes were made to > > collections > > > after 3.0 and the next planned release is 3.1. So, since you haven't > > > released 3.1 yet, you can still go back and fix the incompatibilities. > > > > If only it was that easy :-) The incompatible change is between 2.1 and > > 3.0 - two released versions. The question is what to do about it. > > You're allowed to have incompatibilities between different major version > numbers. A big problem with Collections is its overuse in other commons > components which is in the process of being fixed. Clients don't have to > migrate to 3.0 if they don't want so I don't see a problem. If there's > demand you can always release bugfixes from the 2.1 series (ie. 2.1.1). >
For what it's worth, my opinion is that things are ok as they are. It is valid to introduce binary incompatibilities for major releases. Ok, these ones weren't intentional, and could have been avoided. But projects that use commons libs should have a plan for migrating across major lib releases. Ok, it might slow the adoption of commons-collections 3.0, as projects wait for new releases of all the other commons libs they depend on so that none of the other libs require collections 2.1. But they'll get there eventually. If you really feel like releasing a 4.0, that would be a solution. But I'm not sure projects will be happy leaping from 2.1 to 4.0, so this may not speed up adoption of the new version anyway. I certainly don't think a 3.1 release which is incompatible with 3.0 is a good idea! Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
