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]
