commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject [proposal] avoiding jar version nightmares
Date Thu, 16 Dec 2004 15:03:58 GMT
Hi all,
As commons components gain more and more attention you'll find a lot
components in larger java based projects. This can cause much trouble when
subprojects use different incompatible versions of the same component.
I was faced with this problem in the project I'm currently working on and
thought about how to avoid situations like these.
So this is my proposal:
- All versions of a component using the same main version number must be
upwards compatible: Methods in component-1.x must not change in semantic or
syntax compared to component-1.y where x < y. Methods can be marked as
deprecated but must still work in the same way.
- When incompatible api changes or semantic changes of existing methods will
be introduced, a new major version number must indicate this. To ensure that
different versions of the same component can be used by a single
application, the package name must change as well.
Example:
org.apache.commons.component-1 contains the 1.x source code of the
compoenent
org.apache.commons.component-2 contains the 2.x sources

Both versions of the component can be used simultaneous and situations
described at the beginning of this post can be handled.
Disadvantage: When upgrading a project from component-1.x to component-2.x
all includes must be updated.
But the fact that many (even commercial products) ship without indicating by
jar-extension which version of a component is used, this can avoid a lot of
headaches.
What do you think of this approach?

Regards,
Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message