Struts uses the deprecation cycle I described and so did the commons components spawned from Struts the last I knew (validator certainly still uses the described cycle). A 1.x series is backwards compatible but deprecated methods may be removed after they have been deprecated for at least one point release. A jump to 2.x means, among other things, there are backwards incompatible changes without a deprecation cycle.
This approach obviously varies by project. David --- Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Commons has always followed a longer deprecation cycle than described > below. > A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0. > > 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] > > __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
