Re: pear installer in PHP 5.1 RC1

Lukas Smith wrote: > Clay Loveless wrote: > >> What about non-critical bugs? By breaking things down into smaller >> components, it's easier to make smaller, incremental enhancements -- >> as you >> already know, I'm sure. > > > I think this is exactly what Pierre is worried about. In the past we > have had issues with packages that the PEAR installer depends on > getting non critical releases that led to BC breaks. As such any > package that PEAR depends on really needs to get much more indepth > testing for _any_ release. Pierre is indeed worrying. What he is also doing is expressing an uninformed opinion and raising incorrect FUD surrounding the change, and not because of any actual problems in the code or the package. First of all, any *casual* examination of the code would show that there is absolutely no BC break. Pierre is unfortunately demonstrating his lack of time more than his rank as lead of PEAR with this argument, and I find that very disappointing to say the least. I am spending my time rapidly finding and fixing problems with PEAR 1.4.x, pearweb and peclweb. The time I must take to explain that which I have already explained months ago could be better used continuing that coding. 1) package.xml version 2.0 required dependencies are always installed 2) users upgrading from PEAR 1.3.x will get PEAR/ErrorStack.php because it is still in both package2.xml and package-PEAR.xml!! (Again, casual examination of the file would reveal this fact). The package2.xml file also contains a <ignore name="PEAR/ErrorStack.php"/> that cleverly prevents installation of the file, allowing the PEAR_ErrorStack package to do this. 3) again, users upgrading from PEAR 1.3.x will not experience a file conflict because of the use of the <subpackage> dependency instead of <package> dependency. 4) the use of the <recommended> tag in the dependency will *prevent* casual upgrade for a non-critical release preventing the following: > So thinking a non ciritical release for a package that PEAR depends on > would be less work is just taking a huge risk. Unit tests might reduce > that risk considerably, but its still not clear cut. Indeed, such control is critical for PEAR. Here is 2 sample release sequences: 1) PEAR 1.4.0a13 is released --- PEAR_ErrorStack 0.8.0 is released 2) PEAR_ErrorStack minor bug is discovered, and 0.8.1 is released 3) after early adopters have tested it with PEAR on their sites and all is fine, 4) PEAR_ErrorStack 0.8.2 is released with a <compatible> tag saying it works with 1.4.0a13 or 1) PEAR 1.4.0a13 is released --- PEAR_ErrorStack 0.8.0 is released 2) PEAR_ErrorStack minor bug is discovered, and 0.8.1 is released 3) after early adopters have tested it with PEAR on their sites and all is fine, 4) PEAR 1.4.0a14 is released with a <recommended> version of 0.8.1 In neither case will it be possible for casual users to accidentally hose their PEAR installation. I spent months coding and testing this feature PRECISELY BECAUSE OF THIS PROBLEM. Instead of bemoaning the problem of dependencies breaking the installer and building bloated packages, it is far better to fix the problem of dependencies breaking the installer, wouldn't you think? PEAR 1.4.x literally *cannot* be broken by a borked Console_Getopt or Archive_Tar release because of this feature. They could release something that installed gobbledegook and it wouldn't affect anyone but power users who used the --force option to upgrade, giving plenty of time to pull the faulty release. Now, can we stop this pointless arguing started by a misread of a commit message? I don't think it is too much to ask *as a minimum* that criticism of code be based on the actual code itself. Greg