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

On 10/1/05, Greg Beaver <greg@chiaraquartet.net> wrote: > Justin Patrin wrote: > > On 10/1/05, Pierre <pierre.php@gmail.com> wrote: > >>Once 5.1 is out, we can make 4.3 the minumum requirements. But droping > >>4.x support in any PEAR 1.x releases is not possible, or we drop all > >>the rules which make the quality of our releases. > >> > > > > > > I agree. Dropping support for PHP4 constitutes a BC break. Think of > > Joe Developer, who upgrades PEAR-1.4 to PEAR-1.5. Oops, PEAR breaks. > > This is what defines a BC break. > > Not so. For devs with PHP 4: > > $ pear up PEAR > error: dependencies failed (requires PHP > 5.0.0) > > For devs with PHP 5: > > $ pear up PEAR > upgrade OK channel://pear.php.net/PEAR-1.5.0 > > > 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. > > 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. > > 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? > > 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. 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). -- Justin Patrin