Re: Re: deprecating

On 7/19/2005 7:15 PM, Joshua Eichorn spake the following words: > Lukas Smith wrote: > >> Joe Stump wrote: >> >>> OK, >>> >>> On another note, what if I have an old package (I do) that has a >>> function named foo_bar(). This package has only one stable release >>> (0.2) and one beta release (1.0.1beta). Can I deprecate foo_bar(), >>> have it call fooBar() and then throw a notice that it's deprecated >>> when it's used? >>> >>> If so, then how long do I have to wait to finally remove the >>> deprecated function? One release? Two? >> >> IMHO you cant deprecate a method inside a major version, since that >> is effectively a BC break. > > You can still change the api in anything that hasn't has a stable > release right? Yes, but in this case, I recall the "stable" release was 0.2.0. Now, that's not a "true" stable release according to the new QA rules (because you can't have a "stable" 0.x.x package). Which is why, in HTML_CSS (which is in the same pickle, btw, due to historical factors), I'm going to roll out a completely new API for 1.x, but... I'm trying to "grandfather" the old methods in wherever possible (as Helgi suggested in your case). Yeah, noting that it's deprecated in the apidocs, throwing a notice (that can be suppressed for the package by defining a constant) and not including it in the end-user documentation (but maintaining it for the life of 1.x) is probably your best bet. Hope this helps, Klaus