Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

On Thu, 25 Sep 2003 16:12:59 +0200 "Daniel Khan" <dk@webcluster.at> wrote: > Pierre-Alain Joye wrote: > > > > THE ULTIMATE QUESTION THAT SHOULD BE ANSWERED BEFORE > > IMPLEMENTING THIS > > > 1) There are people who may need to run several mostly > > API-compatible > > > versions of a package at once. What exactly prevents them > > from doing > > > the custom versions themselves, when needed? Why should this be > > > mandatory and implemented at the PEAR framework level? > > > > __VERY__ good question. > > > > I like to see this kind of huge document to describe this RFC, > > really. > > Fully agree - the whole ruleset is much too complicated to communicate > to all developers. > > > Commercial companies with commercial projects should plan > > better their product life and expect a major version upgrade > > as soon as possible. A major release does not happen every > > days god makes for every big package. Small packages do not > > need it as it's so easy to manage them or port an app that > > uses it, or as suggested do this handling BC themselves. > > Don't agree. You seem to always think about dedicated server > environments but what if a hoster has 1000+ users/server and > only 40 rely on package XY which API now has changed. I do not. And I think this hoster should think to install only the core. His users can then install whatever packages they need in their tree, both can live together, having core in the common part and userland packages in another, as far as it allows to change the include path (if he does not I wonder why he still get tousands of user ;) ). > Just thing about TreeMenu. If the API changes all websites > using it to create the navigation will stop to work. > Now have fun migrating 40 sites at once in one night. > The hoster won't ever be able to migrate to the new version. Explain me what will make you upgrade it suddenly only because a new major version has been released? Did you not see the previous alpha/beta before? > > If a company do not have the time/ressource to do it, hey, > > many of us work with php as professional, they can ask the > > author or someone else to do the job :-D > > Sorry - but that's pretty odd. > Let's get rich and do a major API change of some common native php > methods? Does php extension support what you would like to get? Do we have to support that for PECL? I doubt. > O.K. however - to keep things as they are is not the right way to go > IMHO. We have to find a way to allow concurrent versions of one > package on one system. Write a script to do it themselves is maybe a good choice.... pierre