If components stay backward compatible there of course is no need to include the versions in the package name. But I assume that there are some components that have incompatible api changes (or even worse: same api different behaviour) between major version numbers. For packages like these the versioned package names would be the only way (beside renaming the component ;-) to solve this issue. Or have I missed something? Cheers, Daniel
> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Stephen Colebourne > Gesendet: Sonntag, 19. Dezember 2004 23:46 > An: Jakarta Commons Developers List; [EMAIL PROTECTED] > Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > > 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. > > If by this you are suggesting that [collections] 2 and 3 were designed to > be > incompatible then you are wrong. [collections] v3 'moved' classes to new > packages, but _left_the_old_ones_deprecated_. > > Some months later I discovered an unintended incompatability in > IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the > 2.1.1/3.1 combination of versions. > > My point is that they were desinged to be compatible from 2 to 3. > > Stephen > > > > --------------------------------------------------------------------- > 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]
