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

On 10/2/05, Tobias Schlitt <tobias@schlitt.info> wrote: > 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. True, but people will also try to test in one place and copy to another. Yes, if people don't realize that PHP5 != PHP4 it's their own problem. The above aren't the big reasons, though. See below and my other responses in the thread. > > >>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. Well, I say if it's not E_STRICT compliant, why pretend that it is? Still, though, this isn't a major point. > > >>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)? Because we're going to have 2 branches for the same package which are developed and released in parallel. One is PEAR 1.4.x which is for PHP4. One is PEAR 1.5.x which is for PHP5. When we were dealing with PEAR 1.3.x and 1.4.x this was at least obvious due to states on the packages what was happening (and easy to deal with in the installer with preferred_state). But with 2 stable "branches" being released on the same package we have confusion. If we have 2 branches of a package they should be *different packages*. 2 release branches within one package is not an ok thing. Again, we can't compare PHP to PEAR. PHP is one monolithic beast where you use one version at a time. There are branches for 4.4 and 5.0 so that different major versions can be bugfixed and released seperately. The 5.1 and 6.0 branches are dev branches and will be released as such until they are produciton ready. In 5.1's case once 5.1 is stable, the 5.0 branch will be *abandoned* as 5.1 will be the new 5.0. The same goes for PEAR package. If you start releasing stable 1.5 it should replace 1.4, not be a seperate release branch. This breaks the whole idea of major releases and our version #'s. 1.4=>1.5 is supposed to add new features, not be a newly created package (as switching to PHP5 essentially makes it). > > > 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. I disagree with your last statement. This is not a problem with the installer. The installer has been made with the assumption that the latest version of a package in a certain state is the one that should be installed. This is a valid assumption and should be kept as such. I don't think that the installer should have a hack to allow it to search through all newer versions searching for a dep that it can satisfy. -- Justin Patrin