[EMAIL PROTECTED] wrote: > On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton > <[EMAIL PROTECTED]> wrote: > >> I would agree that for Lang that *if* the API change breaks >> compatibility, then a package name change would be appropriate - but >> I think its a mistake in general to start making decisions along the >> lines JDK 1/5/Generics == package rename BEFORE there are any >> concrete proposals on the table. > > Perhaps we need to come up with a standardized versioning strategy for > Commons projects, then. A simple rule might be that if you're > breaking compatibility, you have to jump major versions and change > your package names (I would argue that whenever we jump version > numbers, we should change package names to match to keep things > consistent). I keep bringing this up, but it never gets anywhere. > I'm kind of stubborn like that I guess. :) > > If merely jumping to JDK5 language level doesn't break API > compatibility, then let's not jump to a new major version.
Well, just to throw in a different thought: Package name change is only necessary if both versions implement types with same names that are incompatible. That is what ASM did and why the problem exists at all. If only one class of 100 is incompatible, it might be better to introduce the new one with a different name instead of renaming the complete package. However, this only applies if the new version is a drop-in replacement. If classes have been removed (like the enum package), it must be still possible then to have both versions in the CP as long as the new one comes first. Nevertheless this scenario is much more difficult to handle and from the maintenace PoV it might be easier to rename the package altogether then. Therfore - depending on the nature of change - we can either introduce a new class name, rename only a subpackage or do so for the complete project. Additionally we can always ship an additional compatibility package that can be used as complete replacement of an old version in combination with a newer one. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
