Re: Re: move PEAR to PHP 5-only?

Hi Justin Patrin! On 10/01/05 22:18 you wrote: >>>Now, it is certainly possible that you can add a PHP5 dependency to >>>the PEAR package.xml, but this is only a quick fix for the above >>>problem. Anyone using PHP4 will be shut out from updates and bug fixes >>>in the 1.x line. >>Also not so - PEAR will prevent upgrading to a PHP5-only version. We >>can continue to support 1.4.x in the same way that 1.3.x was supported >>while PEAR 1.4.x was being developed. > Sure it will, but dealing with upgrades and such *is* a problem. Not > to mention that this is very confusing. I don't see either of these points. PHP version smaller than 5.0 will simply not be supported for PEAR 1.5. So what? Where is the point? And how can that be confusing? Do you expect PEAR to support PHP 4 until PHP 6 is out? >>>To move to only PHP5, PEAR will have to move to PEAR2 as this is a BC >>>break. You're welcome to take the current code, make it PHP5-only, and >>>rename it PEAR2, but I doubt this is what you want. >>BC break = packages that depend on it stop working. This will not >>happen. For instance, packages that use actual PEAR code: >>- PEAR_PackageFileManager >>- PEAR_Info >>- anything that uses PEAR_Error >>- anything that extends the PEAR class > Except that if you use the new version on PHP4 it *will* die. You can't. Fullstop. The only way to install PEAR 1.5 on a PHP 4 system would be a "$ pear upgrade -f PEAR-1.5", which is completly stupid. >>will all continue to function normally in PHP 5, just as they do now. >>The only difference will be the internals of these classes, which is no >>business of these applications. Code like: >>if (PEAR::isError($blah)) ... >>will continue to work. >>Unfortunately, this will never be E_STRICT compatible because PEAR was >>stupidly designed to allow the same method to be called both statically >>and with an object instance, and so we can't fix that. Other things can >>be fixed, however, moving closer to a PHP5-based PEAR without requiring >>a complete rewrite. > Meaning that PEAR as it now stands can never be fully E_STRICT > compliant without breaking BC, correct? Correct. But that's not the goal we are talking about here. There will always be some parts which cannot be made E_STRICT (as shown) until we start PEAR 2.0, but it's a good start to modernize the PEAR sources. Beside that, it will allow us to use PHP5's features for new features, which is great. >>A rewrite of PEAR to take advantage of new features in PHP 5 will take a >>year or more, anyone who says otherwise is trying to sell snake oil :). >> There are many considerations, such as whether to get a basic installer >>built into PHP as an extension (a very good idea), and how to do that. >>No, this will not happen overnight. > I'm worried about 2 things. > 1) Maintaining 2 minor versions of the same major version of PEAR for > different PHP versions is confusing. The PEAR site will only show > *one* newest stable version and this will be 1.5.x. If someone is > using PHP4 they won't be seeing their version. This is also confusing > because you're treating one package, PEAR, as 2 logical packages, PEAR > 1.4.x (PHP4) and PEAR 1.5.x (PHP5). The PEARweb pages are set up to > handle *one* package per package page, not 2. It simply does not make > sense to be maintaining 2 seperate versions of PEAR on one package > page. This will cause major confusion for users and lead to all sorts > of support questions. I still don't see the point. The package-info pages surely will list 1.5 as the newest version, so what? I don't believe that users are that stupid, that they don't realize that the new version is PHP5 only. Beside that, one can simply mention this fact in the package describtion. IIRC PHP currently maintains 4 branches: 4.4, 5.0, 5.1 and 6.0, so why should it be that hard for us to maintain 2 versions (what we already did in the past, as Greg mentioned)? > 2) Will the PEAR installer be smart enough to upgrade to PEAR 1.4.3 > when 1.5.1 is out? If I'm at 1.4.2 and try to upgrade it will find the > newest stable release, 1.5.1, and try to install. This will fail due > to a dep on PHP5. So even though I *could* upgrade to 1.4.3 the > installer won't because there is a newer stable version. I *may* be > wrong about this, maybe the installer can do this, but I don't think > it should. We have the BC rules in PEAR so that if you're using a > package you can continue to use *any* version of the package without > changing code (or, IMHO, your setup). Ok, I can see a valid point here. This is a general problem with the Installer itself, of which we have to think. Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for php http://www.schlitt.info Like to say "thank you"? - http://pear.php.net/wishlist.php/toby