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

On Thu, 25 Sep 2003 16:51:50 +0400 Alexey Borzov <borz_off@cs.msu.su> 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. However I strongly disagree to add this kind of things to PEAR. We all got problems with the exact same behaivors in our different systems and/or app (i.e. for libs). A bad side effect is that will increase the amount of packages and/or external packages/apps that will rely on old packages for months (years?). External projects (OS) can ask for help/contribution to port the codes to the new package(s). 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. 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 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. pierre