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

Sorry to top post, but I would like to make several general statements. It is seems to me that the people against this seem to mainly be saying that this is unneeded complexity. 1) I question why none of these people posted anything when this first was raised by a PEAR package that depended on the Log PEAR package which introduced a minor BC break in a non major release didn't get updated **IMEDIATELY** and someone asked about it. Greg, et. al., are not making up a solution that needs a problem, the problem already exists. Arguing whether the problem exists or not is pointless. It has been demonstrated. Please read the archives. 2) It is fairly obvious that some have never taken part in a large, distributed development project. We have to go back only a few years to find code that had not been touched for 30 years and caused the "Y2K" crisis. There was much code that I worked on that depended not just on 2, but 3,4, or 5 revisions of the same library. There were some mainframe apps that had multiple formats of file based dbs such as Berkley DB. 3) First the argument is that drive space will be wasted, then that each person in a hosted environment should install their own copy of libraries, that every app should install their own version of dependencies. 4) First the argument is that upgrades will no longer be transparent. Then that the installer should support munged install paths which apon upgrade will require the app to be touched.. All of this when the RFC defines that the major version will not change unless there is BC, which requires the app to be touched. 5) Then the arguement is made that on BC breakage, PEAR contributors should be able to solicit help from other PEAR contributors to fix their module, when that isn't happening now on simple stuff like documentation and testing. Strong versioning controll HAS TO been in place for a distrubuted project to be well used, well organized, and not avoided. Thanks, Rob > -----Original Message----- > From: Stefan Neufeind [mailto:stefan@neufeind.net] > Sent: Thursday, September 25, 2003 10:25 AM > To: pear-dev@lists.php.net > Cc: Daniel Khan > Subject: 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 > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >