commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [lang] Java 5
Date Thu, 12 Jun 2008 12:10:37 GMT
jcarman@carmanconsulting.com wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <niall.pemberton@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message