1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
1.1/1.2 -> 2.0 may cause issues.
In collections we faced a peculiar compatability problem in that a constant was in both 2.1 and 3.0 but was declared as a different type (by error). This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to get around the problem).
Personally, I believe that a different package name for each version is overly restricting. Most users will just recompile their code for the new version and it will just work. Plus, having the same class in two different packages will be very confusing when using an IDE. This would be especially true if someone obtains an object from one version and then tries to pass it to an object of another version.
Also, since human error can be a factor, we would have to version every release, minor or major to actually make the system foolproof.
Basically, I believe there is no simple solution to this. The best we can do is to encourage tools like clirr which check a library for binary compatability. This should become part of each components standard tests.
Stephen
----- Original Message ----- From: "David Graham" <[EMAIL PROTECTED]>
All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users.
The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies.
What commons components caused your project problems?
David
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
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]
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--------------------------------------------------------------------- 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]
