Re: Proposal of removing PHP4 references from the manual
| From: | Maciej Sobaczewski | Date: | Mon, 14 Jul 2014 17:49:11 +0000 |
| Subject: | Re: Proposal of removing PHP4 references from the manual | ||
| References: | 1 2 | Groups: | php.doc |
| Request: | Send a blank email to phpdoc+get-969385039@lists.php.net to get a copy of this message | ||
Hello Hannes,
On Sat, Jul 12, 2014 at 11:44 PM, Maciej Sobaczewski <sobak@php.net> wrote:Respectfully, I don't think so. Right, most of the extensions not available for PHP 5 has been removed, but there are still tons of references to PHP 4 which are distracting users. Some examples: - "zlib: PHP 4.0.4 - PHP 4.2.3 (systems with fopencookie only)" wrappers.compression.php - "Enable transparent session id propagation. Only valid for PHP 4.1.2 or less. From PHP 4.2.0, trans-sid feature is always compiled." - configure.about.php - "Available since PHP 4.3.0" - so many places - "These filters are <emphasis>not</emphasis> available for PHP 4." - filters.php - many INI directives are not available in PHP 5.x - IMO directives available since PHP 4.x shouldn't have any additional notes, like directives available as of PHP 3. If we assume that base version for the manual is 5.0.0, it means that they are just available from reader's point of view. That's all. - "Since PHP 4.0.2, <constant>__FILE__</constant> always contains an absolute path with symlinks resolved whereas in older versions it contained relative path under some circumstances." - "Prior to PHP 4.0.6, the behaviour of the <function>tempnam</function> function was system dependent. [...]" - rather long note. - way more That's what I'm talking about. As you can see, these are mostly inline references. I think that removing them will be beneficial for the readers. Basically, it means less amount of text to read. Currently they have to, at least, read begin of the sentence and if it beginns with "As of PHP 4.x", then they can skip this sentence and read next one. This is automatic process, of course, but it also takes some time - especially when considering manual as big as ours. When it comes to versions.xml - they are not a problem, I agree. "PHP 4" info can stay. On the other hand - there's nothing about "PHP 3" or "PHP/FI" - it means that "PHP 4" segments are going to be removed, sooner or later.*Dealing with removal* - determine base version described in the manual - probably just 5.0.0 to omit additional confusion - remove all entries from changelogs for versions lower than PHP 5.0.0 - remove functions not available in PHP5 - remove extensions for PHP < 5.0.0 (if we have such) - remove all inline references, notes etc.I thought we did this already? (with the exception of removing PHP4 from versions.xml - which I don't really see a benefit - its imo is a fun history "fyi"?)
ext/domxml is no longer available. neither is ext/overload. php.net/oop4 was moved to the Appendices...Hm, I'm not sure if I unterstood those entries correctly, but I probably found few more extensions for PHP4 only: - dotnet - greater part of com - hw - swf
What else is PHP4 specific? We've also tried to remove any inline version info, not just php4 oldies, as it reads wrong anyway - we've even extended docbook to make it possible to keep the version info at the top available outside of refentries. Without a concrete action any decision here is useless - like you are referencing... stuff was decided almost a decade ago and still not implemented... If you find anything that is burried in deep dark places.. Feel free to fix it :) People complaining about keeping a "PHP4 historic version" are roughly 5years late to the game.Please, don't get me wrong. I absolutely don't want to complain. I'm ready to work, to improve docs. But first, I want to ask if I am allowed to do this ;)
We could resurrect overload and domxml and export into .html page like php3.php? Is that what they are asking for?I think that providing compressed/online snapshot of specified revision somewhere on doc.php.net would be more convenient and even easier to prepare for us. Opinion based on post written by Chris Wright in this topic.
-HannesBest regards, Maciej.