There is sort of a guideline at http://jakarta.apache.org/turbine/maven/development/deprecation.html This has not been adopted formally however.
Collections 2.1 will deprecate a number of classes. I would hope those would be removed in a 3.0 release However, it may be 4.0 or not at all I can't say. FYI, the current release cycle seems to be about every 6 months, although it should probably be quicker. Stephen ----- Original Message ----- From: "Jason Gillam" <[EMAIL PROTECTED]> > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
