Re: Looking towards PEAR2?

Joe Stump wrote:

Per our amazingly shortsighted CS I thought of a serious problem having to do with the "Major new revisions must be named PackageX where X is the new major version". What happens when PEAR moves to the next major version? Will it ship on PHP as PEAR2? Will I then have /usr/bin/pear and /usr/bin/pear2? Will there be two different directories containing PEAR modules (one for ones installed via PEAR 1.x and one for ones installed via PEAR 2.x)?

The major version number indicates a break in BC for a package and little else. It appears that you are blurring the lines between pear and PEAR. PEAR is a package just like DB and Console_Getopt. If the package PEAR needs to break BC for some reason a new package called PEAR2 should be released. This way your PEAR::isError calls are garunteed to still work when you install the new PEAR2 package. The package with the new version number is an entirely new package. The fact that it has the same base name implies that the two packages serve the same basic purpose. The install directory for packages will not be modified by a new major version of PEAR. It will still be /usr/share/pear/ (or what ever you have set). It will contain two directories for the PEAR package (/usr/share/pear/PEAR/ and /usr/share/pear/PEAR2).

Will PHP ship with both and then, at compile time, you'll have to choose which one to install? Per the CS rules the package will HAVE to be named PEAR2. Does this mean I'll have to change all of my PEAR::isError()'s to PEAR2::isError()?

Assuming isError has changed between the two major versions, AND you want to take advantage of the "new and improved" isError then yes. If the old isError works good enough, then you don't have to do anything because your PEAR 1.x package is still installed. Scott Mattocks