Re: [RFC2] Handling Backwards Compatibility in PEAR

Stefan Neufeind wrote:

Well, if we (Alexey and me) mis-understood each other *that* much then Greg you're right ... and my apologize go to Alexey for mis- understanding him. The way I understood Alexey was that "a complete API break" or "complete rewrite" would require a new major version. But "minor breaks" could be solved also inside the same major version. And that's what lead me to the point of thinking "hmm, renaming a function is only a minor break so he didn't want to bump the major version so users might get into problems". I didn't read this in what Alexey wrote, I just figured Alexey was defining version numbering. The problem of minor BC breaks is the reason why it needs to be possible to do this versioning scheme:

Foo 1.0.0 Foo 1.0.1 bugfixes Foo 1.1.0 feature additions Foo 2.0.0 minor BC breakage - the package is essentially the same, users must do text search-and-replace for a few methods Foo 2.1.0 etc. Foo3 3.0.0 MAJOR BC breakage - whole API is reworked to give major new features not possible with Foo 2.x, give users whose apps only need the functionality of Foo 2.x no need to rewrite their apps, and allow newer code to co-exist if necessary with older code until the old code is rewritten in the future. In this way, minor BC breakage doesn't require any change to namespace. This is also why I wrote the patch to check on major version upgrades Greg