Doc->Req #60566 [Bgs->Opn]: Highlight prototype changes
| From: | philip@php.net | Date: | Thu, 29 Dec 2011 19:54:05 +0000 |
| Subject: | Doc->Req #60566 [Bgs->Opn]: Highlight prototype changes | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-7714@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=60566&edit=1
ID: 60566
Updated by: philip@php.net
Reported by: martinb at online dot ie
-Summary: Highlight that 3rd argument $matches only became
optional in 5.4.0
+Summary: Highlight prototype changes
-Status: Bogus
+Status: Open
-Type: Documentation Problem
+Type: Feature/Change Request
Package: Documentation problem
Operating System: Ubuntu 10.04
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
Yeah, the "bogus" label is questionable but it's been here since the 90's. One
day someone will change it, I reckon, and perhaps that day we'll also change
"Wont fix" to "Won't fix" although I like that one. :)
I wonder if we could add a little trickery to make the prototype changes clearer,
in terms of versioning? Maybe a little [note] overlay of some sort, and/or a
simple indication. Probably only for the phpweb version.
So this bug report is turning into a feature request for something along those
lines.
But to be clear: This is not asking for version specific PHP manuals.
Previous Comments:
------------------------------------------------------------------------
[2011-12-29 19:42:17] martinb at online dot ie
Hello? Please relabel the report "Closed" or "Rejected" or something accurate.
Failing that please remove it and my email address from your system.
------------------------------------------------------------------------
[2011-12-22 11:09:17] martinb at online dot ie
The backwards compatibility of the *documentation* is affected because it's misleading. This
isn't like other cases where a parameter is made optional and defaults to some value, this is a
fix to a usage case of preg_match_all (counting instances) where the matches parameter should never
have been required and thus it's natural to assume it's always been the case.
Re "Bogus": words matter. If you don't mean bogus then please relabel the report
"Closed" or "Rejected" or something accurate. Failing that please remove it and
my email address from your system.
------------------------------------------------------------------------
[2011-12-21 21:38:43] frozenfire@php.net
Please don't take the marking of your bug as "bogus" to be an insult. What often
occurs is that we go through a slew of bugs quickly and weed out the ones we
won't or cannot fix. Bogus usually means that a submitted bug asks for a solution
which would be contrary to our documentation style.
In this case, we usually only represent changes to functions in the changelog.
It's rare that we will make additional mentions of changes, and those are only in
cases where backwards compatibility is severely effected.
------------------------------------------------------------------------
[2011-12-21 19:16:51] martinb at online dot ie
Did I say they shouldn't? Other changes to functions are highlighted at the top of the
document: fgetcsv is a particularly good example.
Also, is it standard to mark rejected bug reports as "Bogus"? Whether this gotcha (got me
anyhow) merits highlighting may be moot but the report is not bogus, and it's pretty
objectionable to be so labelled.
------------------------------------------------------------------------
[2011-12-21 14:29:46] bjori@php.net
No, all changes to functions are described as changelog entries
See http://www.php.net/manual/en/about.phpversions.php
for more details on which
versions we document.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60566
--
Edit this bug report at https://bugs.php.net/bug.php?id=60566&edit=1