Re: [RFC2] Handling Backwards Compatibility in PEAR

On 21 Sep 2003 at 7:42, Tomas V.V.Cox wrote: > Saturday, September 20, 2003, 11:55:21 PM, you wrote: > > > What if he installs two apps (app1 and app2) where one is written > > for the "old" Foo 1.5 and the other already updated for Foo 2.1 > > (mind: it's not Foo2 2.1 here!). Then you can't demand of a "dumb" > > user that the crawls through app1's sources and updates them to use > > api 2.x. Having Foo and Foo2 the problem would be automatically > > solved. > > > At the moments I see only good reasons for such a consequent / > > consistent way to go. And since we would also update pearweb to just > > display a package "Foo" with multiple versions there wouldn't even a > > problem with having Foo, Foo2 and Foo3 some day in a search-result - > > these would be centralised as "Foo" like it is now. And everything's > > fine again. > > > It would be nice if you could please outline your thoughts why such > > a way would be really bad in your eyes - now I outlined all the > > pro's I see in the consequent solution of versioning. > > Sorry but that sounded funny to me in the first look. I was the guy > who proposed originally the Foo/Foo2 idea and will one of the guys who > will work on it. And I know that I didn't like it at all in the first place :-) But now that we've discussed everything in that much detail I see the need. And it's seems the only *good* solution we have ... > My point with my mail, was just that I don't find a bad movement the > fact to ship certain libs within your app. In general your right. But by shipping them with your app you might loose the feature that your app might / will benefit from updates and updates on a server will, most of the time, be done only centrally (to the "common" pear-installation). Stefan