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)? 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()? Wow, that'll suck big time. --Joe -- Joseph C. Stump joe@joestump.net http://www.joestump.net And an on topic reply.

I realize that the "Major new revisions must be named PackageX where X is the new major version" really bothers you and a few others. Maybe this is because you don't want a package with a version like 1.999 and i guess thats understandable. The goal of this is to keep peoples current code from breaking when bc changes are made. A good example of this would be in the PEAR case PEAR2 might not have an isError method at all since its located on PEAR_Error or somethng like that. Doing something like this can be useful as you make apis more sane, but it can't be done without a class rename without breaking tons of code. Maybe CS needs to be updated saying, as long as you don't break BC feel free to raise your packages major version to let people know that major new features have been added etc. -josh