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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
