RE: [PEAR-DEV] [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

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. 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. > 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? > Inside PEAR itself, I think we have a large userbase for the > majority of packages, many of them are even PEAR members. I > do not think it is a problem to ask for help if a maintainer > do not have the time to upgrade his code. > > At least, providing a script to install as major version with > borked path should be quit enoug, imo. 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. And this way has to be easy to communicate to the PEAR devs and the users. regards Daniel Khan