Re: Re: dependencies andapplications
| From: | Stefan Neufeind | 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