Re: Re: Lack of recommended versions of setPhpDep()?

Hey Greg... On Aug 21, 2007, at 1:10 PM, Gregory Beaver wrote:

I misunderstood your request. I thought you meant an optional parameter to the php version for the setPhpDep() function, but you really meant adding a <recommended> tag to the php dependency (correct me if I'm wrong).

Sorry for the confusion, setPhpDep() and <dependencies><php> mean the same thing to me :-)

The reason this doesn't happen is because the <recommended> tag is strictly enforced unless you pass --loose. In other words, you could only specify 1 PHP version that is recommended, and people with other versions, including newer ones, would have to use --loose (or worse, --force) to install.

I don't see "--loose" as necessarily a bad thing. If I release Some_Great_Package and I'm using it almost exclusively on 5.2.2 but quick "eyeball" tests show that it works on 5.2.0 and 5.2.3, my recommendation is 5.2.2, but my minimum is 5.2.0. I could see that as a pretty good benefit in the weeks immediately after a new release of PHP. Recommended would still be one version behind, but it just requires >= 5.2.some-release.

There is no way to specify that a new PHP version is compatible post-release, but there is a way to specify that a new package release is compatible post-release with the <compatible> tag. So, in short, <recommended> does not function the way you think it does (reading between the lines) and would not be appropriate for php version dependencies.

For PEAR packages, sure. You don't want to have 1.2.3.1, 1.2.3.2, etc., etc. just to accommodate re-releases with a new package.xml to show the recommended version has been changed, but I wouldn't say that's a reason to remove the functionality completely for other projects. I will say that <recommended> didn't function exactly as I anticipated. I would have thought it would have displayed a message to the user on install saying something to the effect that you're using a compatible version, but not the one that's recommended. -Travis