To answer your question about the type of policy... well the general policy I'm used to following is a "two major releases" policy (i.e. if you deprecated something in version 1.x, it has to be maintained until 3.0). Since different products follow different release cycles, this seems to make more sense than a time-based model. This being said, I don't expect any of the commons libraries to necessarily follow this exact model. I just think it would definitely be nice to know that there was some sort of deprecation policy being followed so that you know what to look for when you get a new version of the library. In the case of an open source library such as any of the commons libraries, I agree that you could end up with a lot of deprecations if you always deprecated things before removing them; however, if the deprecation happens within a release cycle the deprecation period can be much shorter than deprecating something that was in a previous release version of the library (i.e. if you introduce something before your release candidate, you can get rid of it quickly if you deprecate it before the release).
Regarding Xalan - It wasn't a classpath issue. I don't remember the details offhand, but I think it had something to do with our custom XPath functions. They basically had to be completely rewritten, even after including the Xalan compatibility jar with Xalan 2. Ancient history, to be honest. Jason -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 11:03 AM To: Jakarta Commons Users List Subject: Re: Deprecation Policy Much the same question has been hovering in my mind recently, but from the other viewpoint. Open Source philosophy says to release early, and release often. Creating a library [a lot of Commons are just libraries, though not all. Some like Jelly go beyond this] usually involves waiting as long as possible until a release is made, and trying to avoid ever changing it once it is released. If you go the slow-library [ie) make a release of the JDK once every 18 months, heh, we could even tie releases to releases of the JDK :) ] then a lot of the advantages of the open-source are lost, but if you go the quick-open-source way, then you end up with a very large set of deprecations, or you make users constantly deal with the vanishing of methods. Inside a company, I would usually happily remove a function [ie) not even deprecate it] as the management time of deprecating it just isn't worth it. Break it so they can fix it. But outside? with a fast release cycle? .... To answer your actual question :) I'm not aware of any official Commons policies on deprecation. Things are deprecated rather than just removed [see Commons Collections as an example], but I wouldn't expect that deprecation to last beyond the next release. What kind of deprecation policy are you looking for? Something that says there will be a 2 year gap between code being deprecated or vanishing? [as a harsh example], or something which enforces that all thigns must be backwards compatible? I assume the Xalan issue you had was one such as, a webapp [say Tomcat] with lots of projects in. Project A used Xalan 1, project Q wants to use Xalan 2, but putting the Xalan 2 jar in the web container breaks projects A through P? [assuming that it's not possible for the webapp projects to have their own libraries. so maybe jserv is a better example]. Hen On Tue, 15 Oct 2002, Jason Gillam wrote: > Hello, > I have a general question for commons code... maybe someone on this > list has an answer for me. > > What sort of policy is there in terms of a deprecation path? Basically, I'm > investigating some of the Commons utilities for use in our products but we > don't want to risk any major changes such as sudden disappearing or > unsupported methods or classes without ample warning. Apache has, in the > past, left us high-and-dry (Xalan 1 -> Xalan 2), but we're hoping this was a > one-time thing. What sort of measures does the commons package have in > place to avoid similar issues down the road? If there is a policy somewhere > on the site, can someone point me to it? > > Please advise, > > Jason > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
