Re: [all][collections] Solving binary incompatability
Simon Kitching wrote: 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. For what it is worth, I agree. 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! After reading Simons comments, then re-reading Davids comments, I agree with David - if we were feeling generous, we would release 2.1.1 (or more likely 2.2) with as much of the new stuff from 3.0 as we can (without breaking compatibility) plus the 2.1-compatible IteratorUtils. It would also be nice to release a 3.0.1 with only documentation changes (to correctly document IteratorUtils) if another release of 3.x is not likely to be forthcoming any time soon. I'd hope that 3.0.1 would not require a lot of effort from the release manager. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all][collections] Solving binary incompatability
What should commons do when projects get released with unplanned binary incompatabilities that cause issues, as with collections IteratorUtils? I can see two basic solutions: 1) Procede onwards, and tell users to upgrade to the later version. This may not be possible if two OSS projects have built against two versions of the library. 2) Produce a replacement build that puts the API back to how things were. This causes problems for anyone who built against the newer version of the library. For example, should [collections] next release be 4.0 instead of 3.1, such that 4 is compatible with 2.1 but not 3? Release 3 then becomes deprecated. Or does this just create another round of problems. Any other bright ideas??? Stephen PS. The particular problem is in IteratorUtils where 6 methods and 2 constants changed return type, which is binary incompatible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
We've been using major version numbers to allow non-deprecated incompatible changes. For example, if you deprecate something for 1.1 you can remove it in 1.2 but if you want to make major breaking changes that deprecation can't solve you need to go to 2.0. 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. Or, you could release 3.1 as 4.0 but that seems like a big jump for a small amount of fixable changes. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: What should commons do when projects get released with unplanned binary incompatabilities that cause issues, as with collections IteratorUtils? I can see two basic solutions: 1) Procede onwards, and tell users to upgrade to the later version. This may not be possible if two OSS projects have built against two versions of the library. 2) Produce a replacement build that puts the API back to how things were. This causes problems for anyone who built against the newer version of the library. For example, should [collections] next release be 4.0 instead of 3.1, such that 4 is compatible with 2.1 but not 3? Release 3 then becomes deprecated. Or does this just create another round of problems. Any other bright ideas??? Stephen PS. The particular problem is in IteratorUtils where 6 methods and 2 constants changed return type, which is binary incompatible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
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. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
--- 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). David Stephen __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][collections] Solving binary incompatability
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]
