Re: [RFC2] Handling Backwards Compatibility in PEAR

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. My point with my mail, was just that I don't find a bad movement the fact to ship certain libs within your app. -- Tomas mailto:cox@idecnet.com