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]
