Re: The point (BC breakage)

On 25 Sep 2003 at 20:14, Alexey Borzov wrote: > Hi! > > Greg Beaver wrote: [...] > > This does not reflect reality. Nobody in the world has a central > > install of only the core, and user installs of user files. The pear > > command won't even RUN as non-root. This is a totally bogus > > suggestion. > > Can't pear command be fixed to run as non-root without this RFC? > Thought so. I guess it could. But again from my point of view (and I think that others feel the same way too) you might look at the situation from a wrong point of view: In your eyes every customer could have his own pear-install, okay. But what if a php-user (not meaning 100%- developer) installs a guestbook and a voting-tool or something? First one relies on DB_v5 and the other on DB_v3. Both could run when both packages can be installed at the same time. In your situation (only one package possible per "private" repository) this would not be possible. And in another post you suggested that every developer distributes a copy of all needed packages with his app. This is the wrong way in my eyes because of various reasons. The best would be that if you wish to receive bugfixes and also security-fixes you would have to run a "pear upgrade" per application. And if that upgrades to a version which breaks API you would still have the same problems we wanted to solve by our whole versioning-discussion. For updates in my eyes only a central installation (which is centrally updated from time to time or on a regular bases) is the best solution for this. But we need to be able to handle multiple APIs (major versions). And please don't assume that upgrading might brake your app because the new code might be badly tested. I guess every coder runs his tests before packaging a release and especially tests the updated parts of his package during development well enough. If we can't trust in that we shouldn't trust nobody but our own code. I trust in the packages that are being released - and many others also do - because pear is a high-quality-repository and we have very ambitious developers who try to achieve the best (and release good quality code). Stefan