RE: [PEAR-DEV] [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

> From: Greg Beaver [mailto:greg@chiaraquartet.net] > Sent: Wednesday, September 24, 2003 7:37 PM > [RFC3] Handling Backwards Compatibility in PEAR > Sept. 24, 2003 > Greg Beaver , Lukas Smith > Alexey Borzov, contributor [Announcing API Changes] I want to highlight again why the proposed solution is very important to me. I have an application framework with tons of modules that can call each other depending on the solution needed. Like the Forum Modul might need the Voting Modul in order to attache a vote to a forum entry etc. This means that I can have all sorts of combinations of modules running in one script. So when a new major release comes around I would have to update _every_ single module before I can start making use of the new major version. However until I have done so I cannot use make use of that new major version even in new modules I write. With the proposed solution this is no problem. Modules can use different major versions without this causing an issue if they are called in a single script. I can then upgrade the modules when this modules needs it. I am not forced to upgrade all modules if I only need the new major version in one. Here follows a few other comments. > The postfix format shall be > > _vX > > where X is the major version number. The PEAR directory naming > conventions shall remain the same, but files in newer versions will > follow this format: > > Foo.vX.php contains class Foo_vX > Foo/vX/support.php contains class Foo_vX_support > > Version 1.x of the Foo package will have this structure > > Foo.php contains class Foo > Foo/support.php contains class Foo_support > > This naming convention allows the packages to co-exist while the Foo > package is deprecated: > > Foo.php > Foo.vX.php > Foo/support.php > Foo/vX/support.php To me it is important that applying the post fix change to code requires only a simply regexp: s/FOO/FOO_vX Therefore I would prefer if all files that need to be included by the user should remain in their current location. However the best route would be if you would only ever have to include the core class and the rest is handled by a method loadFile() or something like that. I did this in MDB to prevent BC issues if I change the underlying structure and also to prevent any possible issues from different relative include paths being passed to (require|include)_once. > Example: > 6) release Foo-1.0.1 - stable (BC is not allowed) Ah, doh this is my mistake .. it should read "BC break is not allowed" in all cases where it sais "BC is not allowed" Regards, Lukas