So how should we handle situations where two versions of the same component need to coexist? If I have to integrate two commercial projects where each one uses a different major version of the same component, how can I achieve this? There is no chance to force them to up- or downgrade to the version of the other product. In situations like these you are absolutely lost, aren't you? So my proposal was about to avoid this horrible situation. Any proposals how to solve this issue in another way? Or is this list not the right place for discussing stuff like this?
Cheers, Daniel > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von David Graham > Gesendet: Freitag, 17. Dezember 2004 02:26 > An: Jakarta Commons Developers List > Betreff: Re: [proposal] avoiding jar version nightmares > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
