> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Craig McClanahan > Gesendet: Sonntag, 19. Dezember 2004 23:34 > An: [EMAIL PROTECTED] > Cc: Jakarta Commons Developers List > Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > > > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward > > compatible. Especially, I would even consider it dangerous to replace > > a 1.x version with 2.x without checks just to have a newer version. > > Semantics could have chages. Consider collections from 2. to 3. What > > was done there was perfectly alright. > > Collections was indeed perfectly alright to make > backwards-incompatible changes between versions 2 and 3. However, you > should also note that these changes were *not* universal -- for a very > large number of classes, the calling sequences *are* backwards > compatible. > > Now, let's assume that Collections had implemented the "package name > includes major version" rule. If I had restricted myself to the > (quite large) subset where there was no real change, I would have been > *incredibly* irritated at having to change package names in *my* > application's imports -- just because you gratuitously changed the > package name (and therefore made *all* APIs backward incompatible).
You might be irritated, but I think this is the cost to pay for working around this obvious java lack of managing versioned libraries. I think it's just a matter of getting used to this package naming convention. BTW: Another advantage of this approach would be that imports would indicate which version of the component is in use. I had a lot of trouble to find out, which version of jdom was in use by some libraries as this was not indicated by the name of the jar. Daniel > > Craig > > --------------------------------------------------------------------- > 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]
