Re: [RFC2] Handling Backwards Compatibility in PEAR
| From: | Greg Beaver | Date: | Sat, 20 Sep 2003 15:32:15 +0000 |
| Subject: | Re: [RFC2] Handling Backwards Compatibility in PEAR | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-21843@lists.php.net to get a copy of this message | ||
Stefan Neufeind wrote:
On 20 Sep 2003 at 12:39, Alexey Borzov wrote:This fear is rendered unnecessary by two requirements: 1) BC is always maintained in minor version upgrades (btw Alexey, your clarification is great, can you forward to Lukas?) 2) users can only rely upon public elements, and these will continue to work as documented, so the only breakage that is possible is due to a bug, and therefore if a bug exists, pear revert can be used, the bug reported on pear.php.net, a new release made, and voila, problem is solved. GregStefan Neufeind wrote:Agreed. But you can't say "well, your provider upgraded and now the app doesn't run anymore? your problem.". That's not possible. And as a provider you will always get questions like "was the update necessary" and "everything ran fine - so why did you update" etc.This is not what we discussed, right? This way you can't have a 2.x and 3.0 co-exist on a system. For sure this should be no problem on a computer you're working on - but it might become a problem in webhosting-environments.Lets say this loudly: if you want to fully control your environment, you'll need to keep a private copy of PEAR. If you are using a hosting that does not allow this, tough luck. You get what you pay for, generally.