Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

Hi! Greg Beaver wrote:

[RFC3] Handling Backwards Compatibility in PEAR Sept. 24, 2003 Greg Beaver , Lukas Smith Alexey Borzov, contributor [Announcing API Changes]

Well, having my name up here does not mean that I completely agree with this RFC. I see two major problems with this whole 'BC breakage' stuff: 1) It is a non-issue for most of PEAR developers/users, the only people who complain about 'evil BC breakage' are third-party application vendors and *their* users. These vendors can easily create customized version of PEAR packages even now --- just as Linux distritions do and just as PHP does with its bundled libraries. 2) PHP as a language has no concept of 'package'. Thus PEAR packages are essentially a hack (that somewhat works) and their versioning is a hack upon a hack (that may not work at all). While I do agree that some solution for BC handling is necessary I think that the proposed solution has HUGE potential problems. 1) The proposed handling for mostly-compatible major versions and complete API changes is the same: this adds to confusion. 2) The BIGGEST problem: after upgrading to a new major version of the package I'll have to edit my application even if it is *completely* compatible. This can lead to: 2a) Confusion: release notes state that Foo version 3.0 has major performance improvements, why don't I notice anything after upgading to it?.. 2b) Bit rot: now authors of dependent packages should at least follow the development of their dependencies. Wonderful things can happen when they know that they can always rely on an old and buggy version... 2c) It will be *necessary* to depend on a *specific* package version after implementing this RFC. It is *possible*, but not *necessary* now. 3) This may add complications for package authors, which leads to less packages and slower development 4) This may serve as a good excuse to not have tests, QA process and other necessary things. What are the things I agree with: 1) Handling the complete API changes 2) Announcing API changes (well, I *wrote* this) What I disagree with is having Foo_vXXX for *each* major version. What should be redone: 1) There is no clear definition of 'major' release and no guide to release numbering (Foo 1.x is used as an example of major *and* minor version) 2) It should be pointed out that if you do not intend to follow package development, you should forget about automatic upgrades to major versions and should explicitly depend on the major version you tested it with. 3) It should be pointed out that if you want to have two versions of the same package (Foo and Foo_v2 are *different* ones), you should do the necessary changes yourself. THE ULTIMATE QUESTION THAT SHOULD BE ANSWERED BEFORE IMPLEMENTING THIS 1) There are people who may need to run several mostly API-compatible versions of a package at once. What exactly prevents them from doing the custom versions themselves, when needed? Why should this be mandatory and implemented at the PEAR framework level?