Description: ------------ pear list-upgrades already shows all newer version available within a package's stability level, even if the preferred state is higher, e.g.: pear.php.net Available Upgrades (stable): ========================================= Channel Package Local Remote Size pear.php.net Image_Text 0.5.2beta2 (beta) 0.6.0beta (beta) 60kB pear.php.net Mail_Mime 1.4.0 (stable) 1.5.0 (stable) 22kB pear.php.net MDB2_Schema 0.7.1 (beta) 0.7.2 (beta) 61kB pear upgrade-all should work the same way, so that a package is upgraded if a newer version with the same state than the one installed exists. I have already chosen to install a "weaker" package than my preferred state, so it's safe to assume that upgrades within this state are fine too. The only exception probably is, if a version of a more stable state exists "inbetween". E.g. if I have package 1.0.0beta1 (beta) installed and newer package versions 1.0.0 (stable) and 1.0.1beta1 (beta) exists. In this case I probably rather want to upgrade to 1.0.0 than 1.0.1beta1, though this is debatable and a warning might be sufficient.

Hey Jan, 'pear upgrade-all' shares the new and improved logic of 'pear list-upgrades'. It actually just calls pear upgrade <all packages>, which filters the packages with the logic of 'pear list-upgrades'. So the unnatural behaviour is in 'pear upgrade'. To go with the example of 'Image_Text': `pear upgrade Image_Text` currently gives: Failed to download pear/Image_Text within preferred state "stable", latest release is version 0.6.0beta, stability "beta", use "channel://pear.php.net/Image_Text-0.6.0beta" to install Cannot initialize 'channel://pear.php.net/Image_Text', invalid or missing package file Package "channel://pear.php.net/Image_Text" is not valid upgrade failed I totally agree on your statement about packages that are installed: > so it's safe to assume that upgrades within this state are fine too. So more natural behaviour would be: upgrade ok: channel://pear.php.net/Image_Text-0.6.0beta 'pear upgrade' and 'pear install' are the same function and for 'pear install' this ''state protection'' is necessary, but I agree it isn't necessary for an upgrade. 'pear upgrade' actually thinks it can upgrade, as it gives (when doing upgrade-all): Will upgrade channel://pear.php.net/image_text The code that doesn't allow the upgrade is in Downloader/Package.php::_analyzeDownloadURL() A real solution would be to adapt the behaviour of the downloader and make it more flexible. A shallow solution would be to make 'pear upgrade-all' run 'pear upgrade pkg-latest' OK, it seems ridiciously simple to implement the last behaviour, by adding it to the uptodate filter (see patch attached). I'm keeping the technical details in this comment for other developers.

Note, it breaks a test: tests/PEAR_Command_Install/upgrade-all/test.phpt Unfortunately I don't understand the xmlrpc things.

too late for 1.6.1 except for bugfixes, this can go in 1.7.0

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. This one was pretty nasty to track down for some reason - Tias did good job at pointing me in the right direction.