Re: config bug 2439
| From: | Greg Beaver | Date: | Thu, 14 Oct 2004 11:12:23 +0000 |
| Subject: | Re: config bug 2439 | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-33835@lists.php.net to get a copy of this message | ||
Paul M Jones wrote:
On Oct 13, 2004, at 11:49 PM, Ryan King wrote:Absolutely not a BC break. BC is not defined by what the code does, but by what the documentation says it does. If the code does not match the documentation, you must either adjust the documentation, or fix the code. Users who rely on buggy behavior have to code with the expectation that it will be fixed. This is one reason that providing a method that returns the package version is critical, as it allows: if (version_compare($config->version(), '1.10.2', '<=')) {On Oct 13, 2004, at 11:34 PM, Paul M Jones wrote:On Oct 13, 2004, at 11:23 PM, Ryan King wrote:I have a bug I'm trying to deal with here: http://pear.php.net/bugs/bug.php?id=2439 ... assuming you read the bug report.... Would this be considered a BC break?I would call it bringing the API into conformance with expected behavior per the documentation and intent.
// rely on buggy behavior} else {
// rely on correct behavior} This is exactly why documentation is so important - any package that remains undocumented (most of PEAR) by definition cannot support backwards compatibility. Fortunately, many of these packages are still alpha, and so breaking BC is allowed, but a package cannot be considered beta or stable without documentation. Greg