Re: [RFC2] Handling Backwards Compatibility in PEAR

Hi! Rob Hutton wrote:

Two API incompatible versions are handled by Package/Foo.php containing class Package_Foo Package/Foo2.php containing class Package_Foo2 (An API incompatible rewrite of Package_Foo)

Which is package renaming which you said you were against

I never said that, please check the discussion. In fact I like the idea of Foo2-style packages, because this is the way it is done in other projects.

3) having to fix my require_once calls and class names on each upgrade, even if no BC breakage actually happened

That is the whole point of this discussion. Currently, if someone breaks BC then you HAVE TO FIX YOUR APP ON A RELEASE. Under the new system, you can run against the current version of the library, then upgrade as you have the need/desire.

Yes. So now I *may* have to fix my app on a package upgrade, but after the proposed improvement I will *need* to fix it to do an upgrade. Cool.

4) having an insane counter-intuitive versioning scheme (why not Package_Foo_2003_Advanced_Server, BTW?)

What? We have been discussing versioning schemes that take the best of what we see from other schemes and apply rus consistent with the goals of PEAR development. Again, please check out the archives of this discussion.

This is what I consider a counter-intuitive versioning scheme:

In other words: FOOw x.y where:

    w reflects API version
      allows API Additions
      allows ANY BC breakage not related to bugfixes/security fixes
      allows ANY BC breakage releated to bugfixes/aecurity flaws
    x reflects new features
      allows API Additions
      DOES NOT allow BC breakage not related to bugfixes/security fixes or

major BC breakage

    y relects bugfixes/security fixes
      allows only minor BC breakage directly related to fixing bugs or

addressing security flaws

The problem is, no one does it this way. Even PHP's own versioning scheme is different.