Re: Re: dependencies and applications

On 20 Aug 2003 at 20:59, Greg Beaver wrote: > Perhaps a transition - pear/MDB.php will still be available, but > removed in a later date and replaced with a file that throws a warning > before including pear/MDB/2.0/MDB.php (or whatever the latest version > is) so that it still works, but displays a warning? Might be an idea. Although it's a big step it seems the need for such a solution is there, right? This could in one step be done when we also take the other proposal into consideration that require_once 'pear/Net/something.php' should be used instead of require_once 'Net/something.php' right? Maybe a hard break in PEAR 2.0 implementing all this (and forgetting about all that has been up to now) is not an ideal solution? How about implementing this in 1.3 or 1.4 but storing the files both in MDB/MDB.php and pear/MDB/2.0/MDB.php? It would make sence to do such a step as soon as possible so that coders can use the new paths in their programs. And when 2.0 comes (half a year? a year?) we can drop backward-compatibility at all. But until then people could right-away start changing all sources ... Hmm ... What do the core-implementers on this list say about such a solution? Stefan > Davey wrote: > > Greg Beaver wrote: > > >> Lastly, we need to think about having some sort of "slot" system > > >> such > > > >>> as they have in Gentoo for their ports, whereby you can install > >>> more than one major version of an application. This will mean some > >>> changes to the folder structure, and if it happens should be done > >>> ASAP so that we can just get the change over and done with IMO. I > >>> suggest something along the lines of: > >>> > >>> $php_dir/pear/MDB/1.0/MDB.php > >>> and > >>> $php_dir/pear/MDB/2.0/MDB.php > >> > >> > >> > >> This is better. > >> > >> I really like this idea, and it would work beautifully for > >> dependencies. Definitely a PEAR 2.0 must. > >> > >> Greg > >> > > > > I really feel that if we're going to do this, we should either get > > 2.0 out really soon, or do it in 1.x (bad). Otherwise there will be > > too many scripts relying on the current path system and a change to > > this is going to be met with too much resistance. > > > > - Davey