Re: RE: [PEAR] RE: [PEAR-DEV] dependencies and applications

On 21 Aug 2003 at 15:29, LIMBOURG Arnaud wrote: > > Well, I personally rate a central pear-installation quite useful / > > necessary. And in my eyes we should follow the idea that there might > > an MDB-version from the 1.x-tree and one from the 2.x-tree. If you > > ship every package with every app you can't even centralize updates > > to the 2.x-tree or something. And caching (php-accelerator etc.) > > would also require separate caching per application. Hmm - I'm in > > favour of a centralized solution through pear itself. > > > > As mentioned earlier (but to put it a bit different): > > Maybe having pear/MDB/MDB.php for all 1.x-releases and from PEAR 1.3 > > on also have pear/MDB/1.0/MDB.php is fine. From PEAR 2.0 on we can > > issue the warning as outlined before it still pear/MDB/MDB.php is > > used. And from 2.5 or so we should finally abandone these warning- > > files as well. From 1.3 to 2.0 there would be enough time for every > > package and every programmer out there to update his programs to > > work without any warnings. And when 2.0 comes out there is still > > some time until 2.5 finally breaks BC completely. What's so bad > > about such a solution? > > Only packages would need to be updated. Unless you want your > application to benefit from the latest features of a package there is > no need to upgrade. > > Let's application xyz runs with MDB 1. If it works don't fix it ! If > you decide to refactor then you can well choose to use MDB 2 and makes > required changes. > > To cut things short i'm also in favor of a central repository which > handle versions. like somebody suggested, require 'MDB/2.0/MDB.php'. > Any class of MDB can use a $pkg_version = 2.0; then do require > "MDB/$pkg_version/MDB.php". I mean it's no big deal for packages to > handle that, is it ? No, you're right. Thats a good way to do it in my eyes. Or use relative adressing like the dirname(__FILE__)./../someotherfile.php proposed earlier in this thread. Maybe that's even more flexible. While we're discussing this: If we change path-names to be MDB/version/MDB.php and such, shouldn't we also do "the next step" and introduce the prefix "pear/" or "PEAR/" in the same step? All packages that are updated to support the new numbering-scheme could already use the new pathnames ... Stefan