Compatibility issues should be taken care of by #pike.
I would be nice and swell if a complete paper trail of how all functions and classes changed throughout the ages, but I have some sceptisism how making it harder to write documentation would improve things. If there were hords of eager technical writers begging for CVS-access or at least someone who occasionally lended a hand it would be one thing, but as it is today I think our very limited resources are better spent elsewhere.
However, if you whop together something neat that takes the generated XML-files for autodoc from several Pike versions and presentes the changes between the versions we would all think of it as a good and noble deed.
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-07 01:47: Subject: Re: API version tagging
On Fri, Feb 07, 2003 at 01:30:01AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
Well, I guess it's ok for developers like us, but people coming in to learn pike wouldn't rather be happy if they had to jump between two (or more) sets of documentation.
Why would someone new to Pike be interested in API changes in the first place?
Because they would have started using Pike 7.4 and are interested in Pike 7.5, for example. Or any casual coder who wants to ensure that his/hers scripts will run on several machines with various pike versions. Or not-so-casual coders who want the same but are (understandably) to browse two huge docsets just to find the information that should be readily available at the first sight. Maybe I'm wrong, but such "details" also add up to the quality of software. And, as we all know, Pike's biggest problem has always been the lack of good documentation - since we have a way to change that now, why not do it?
marek
/ Brevbäraren