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

On 25 Sep 2003 at 16:12, Daniel Khan 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. > 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. And he won't have the time to a) fix all "at once" b) test every since step, every single error-condition or so to maintain product quality. Stefan