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

<zitiere wer="Pierre-Alain Joye"> >> 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. Sorry, Pierre, but I disagree with you. Se below plz. > 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?). Why should that happen and what is bad on it? Maybe a package will rely on an old version for month or years, but where is the impact on that? Old package versions cannot be that bad. And if a bug occurs in an old package there will be someone to fix that, even if it's not the maintainer himself. > External projects (OS) can ask for help/contribution to port the codes > to the new package(s). That's a point I agree with. But what about PEAR packages? Would you like to force maintainers to release a new version of their package immediatelly when a dependend package releases? What if the maintainer has no time for weeks to do this. Would you like to leave the package broken for this time? [snip] > 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. Correct. But there will be time a package relys on an old dependency. For this time the whole package will be broken for the complete userbase. You know that some issues get solved very slowly in PEAR and any other OS project, because people only do developement on their fun. > At least, providing a script to install as major version with borked > path should be quit enoug, imo. Sorry, but what does "borked" mean? I think I understood you right, that you wanted to say the script should install a package to a different path? Regards, Toby -- <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);'); function f($a){print eval('eval($a);while(list(,$b)=each($a))echo chr($b);');} ?>