Re: [RFC2] Handling Backwards Compatibility in PEAR

On 20 Sep 2003 at 21:43, Tomas V.V.Cox wrote: > Saturday, September 20, 2003, 6:38:23 PM, you wrote: > > > Zitat von Greg Beaver <greg@chiaraquartet.net>: > > >> Foo 1.1.0 feature additions > >> Foo 2.0.0 minor BC breakage - the package is essentially the same, > >> users must do text search-and-replace for a few methods > > > And the conclusion of this is: > > You don't know what api you have if you do "require Foo.php". > > There are ideas to add an apiVersion() method for our CS. You can also > use the PEAR base class to get the version of a package. Well but would this help? Maybe the apiVersion changed but it's because of a function you don't use in your code or something. Would the app display "Sorry, please update me" although everything should run fine? Maybe api was just extended? I guess an extended API would also need a new apiVersion-value, right? So this wouldn't be the solution to that problem. > > I guess we'll bundle the PEAR packages we rely on with out tarballs, > > as many other developers already do with their applications. And > > they probably have a good reason for this. Let's drop the whole PEAR > > installer and let people download the packages manually from > > pear.php.net, this seems to be the only solutions that will actually > > work. Sad but true. > > What's the sad thing? If I code a big application that relay on > certain PEAR libs I'd ship those with my app. That's what most > comercial apps does, there is only a space waste issue. I slightly disagree with you. Upgrading a package also means that certain compatibility-issues, security-updates etc. might find it's way into the updated packages. That's why I like the idea of having an installer with which you can update quite simple to a new version. And if the api didn't change or was just extended that's no problem. You even have much benefits of having centralised updated libs ... maybe even speed-improvements and such. So packaging the libs with the apps is no way to go from my point of view. And since we want to establish PEAR and the PEAR installer as a tool that's used everywhere maybe our app check deps when it's installed on the server and tell the admin "please issue these commands: pear install XYZ" or something. No problem. Maybe you can see the benefit I have in mind? And the only thing that we would need to demand / agree upon is that a Foo 2.0 would become Foo2 2.0. What's the deal? In my eyes it's consequent and allows centralised installs (and updates) without the fear of API-breaks. And as outlined before: If I break my api because of removing or altering a rarely used function I should think if a) this is avoidable or there might be ways to still leave it in there but mark it deprecated or b) there are other API-changes that might be useful in the next time to clear up things and make them more extendable. So these could all be done at once when doing a major version bump. > The PEAR installer can even help you here. You can have configuration > files for users, applications, hosts, etc. With them you can easily > manage the packages your application may need, preserving for example > your common PEAR installation. Agreed. But the usual case e.g. in webhosting environments and such is that you don't demand that a user with 25mb webspace installs his own copies of all pear packages, updates them separately of all other people etc. but that all users use the common pear libs which are installed by the server-administrator and also get updated centralised. That's a good thing in my eyes! This saves a lot of: - space - trafffic and far more important - work for the individual customer. 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. Stefan