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]>
