Re: Re: dependencies andapplications

From: Date: Thu, 21 Aug 2003 15:31:12 +0000
Subject: Re: Re: dependencies andapplications
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-20286@lists.php.net to get a copy of this message
On 21 Aug 2003 at 17:19, Pierre-Alain Joye wrote: > On Thu, 21 Aug 2003 17:12:27 +0200 > "Stefan Neufeind" <stefan@neufeind.net> wrote: > > > On 21 Aug 2003 at 17:05, Jan Schneider wrote: > > > > > Zitat von Lukas Smith <smith@backendmedia.com>: > > > > > > > The PEAR Installer for applications installs the pear packages > > > > that are needed into a seperate directory. > > > > > > I still don't see a need for this. If one writes an application > > > that depends on a certain version of a package, either the > > > application is badly written or the package maintainer is so > > > unreliable in keeping the api bc that you shouldn't use his > > > package at all. > > > > In some cases you can't avoid breaking BC. Surely this has to be > > done with a major version change (demanded by the pear-rules). But > > what if you or a customer running on your server have an application > > requiring the old API and one requiring the new one? > > Then you can install (and manage) 2 different PEAR trees as you > already manage to web/whatever tree for your 2 applications. No, you can't. We're updating pear on our servers regularly - and globally for all customers (virtual host users). In this case you can't demand that we ask everybody if we may please switch from 1.x to 2.x or if anybody says "my app whoooooed" switch back etc. So having separate trees is no way to go for people not only running a server for themselves. Why wouldn't a solution with a library being in 1.x and another in 2.x be of a good idea? > > Maybe somebody of the pear-group could please summarize the ideas, > > call the public for a vote or do something else to get this thread > > to a definite way to go?!? > > This kind of thing will not (and should not) be thought and approved > in 1 or 2 days discussions on a ML. There are many things to check, > valid, test before choosing one way or another (or drop the idea ;) ). It should not be implemented and released within 2 days, agreed. But as stated in the other mail we shouldn't discuss this so in-depth, let the ideas "float free" and after all this email-traffic nobody will pay attention anymore. Or all emails previously written will be forgotten at some point. Maybe this discussion is getting a bit too complex / diverted. So my intention was that somebody (from the group) could maybe summarize which ideas are good and should be discussed further and which ideas are bad. Also I'd appreciate if this was not done by only one person (from his personal view) but taking a look at how the ML-members reacted, what they thought and what the other group-members think about the ideas. This is getting too much traffic and too much chaos of ideas for me - sorry :-((( Stefan

« previous php.pear.dev (#20286) next »