RE: [PEAR-DEV] [RFC2] Handling Backwards Compatibility in PEAR

> Rob Hutton wrote: > > Simple examples of the need to run two API incompatable > versions of the same > > package have been discussed on the other threads... > > Your point being?.. You have stated that you are against package renaming and the reasons that renameing is "A GOOD THING" have been discussed. > > 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 > Package/Foo.Bar.php containing class Package_Foo__Bar (or whatever) > "blessed" and distributed by application vendor Bar. > Package/Foo.Rob.Hutton.php containing Package_Foo__My_Preciousss created > to prevent evil PEAR developers from breaking applications > > I just don't buy into: > > 1) "no API breaks allowed" bullshit Noone said anything about no API breaks. We are talking about BC breaks not related to fixing bugs or addressing security issues. Which absolutely should not be done except on a major version release. > 2) having a bunch of > Package/1/2/3/4/5/6/7/8/Foo.php > Package/8/7/6/7/9/9/9/Foo.php > and the like Where did this come from. This was discussed, but fairly quickly concerns about maintaining such a structure dismissed. Again, please see the archives. > 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. > 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. > 5) assuming that PEAR users are morons unable to read changelogs > *before* upgrading. If you read the archives, it will quickly become appearant why this statement has nothing to do with the reason that this discussion was started. Thanks, Rob