Re: A proposal regarding function naming, aliasesand such

Andi Gutmans wrote: > Most people don't upgrade from 4.0.0 to 4.0.27 but at least every two or > three versions or so (IMO). thats why i won't push any limits on how long a 'deprecate' function may stay alive (and produce the appropriate warning), only the final 'dead' state (if implemented at all) shouldn't stay to long, it should only be some sort of convenience level before totally dropping out a function but still the 'experimental' state would make sense as it would prevent a lot of backward compatibility problems in the first place as we do not have to care about compatibility too much as long as a function hadn't left the experimental state before > I think (as I've mentioned in the past) the downloads page should list the > NEWS file to make sure that people keep updated with the changes. We are > one of the only projects that keeps a nice and useful news file as opposed > to just and ugly unreadable Changelog file. theese mechanisms are not meant to replace the NEWS and Changelog files, but they might help those users, who overlooked something in the NEWS file, stumble across a change not documented there or do regular updates whithout reading NEWS or Changelog this isn't going to help everybody out there, but it doesn't harm anyone and might help some and if done right i might even be able to extract the experimental and deprecate states and comments for automagical inclusion into the manual as i have done with the version availability information from the function table -- Hartmut Holzgraefe hartmut@six.de http://www.six.de +49-711-99091-77 Besuchen Sie uns auf der Buchmesse in Frankfurt, Halle 4.0, Stand D 1117 und auf der Systems in München , Halle C2, Stand 126