Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.83.42 as permitted sender)
Message-ID: <4F994F0A.4080001@seld.be>
Date: Thu, 26 Apr 2012 15:35:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <4F956B74.4040104@seld.be> <1335197218.7272.109.camel@guybrush>
In-Reply-To: <1335197218.7272.109.camel@guybrush>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Extension versions
From: j.boggiano@seld.be (Jordi Boggiano)

On 23.04.2012 18:06, Johannes Schlüter wrote:
> On Mon, 2012-04-23 at 16:47 +0200, Jordi Boggiano wrote:
>> As you see it goes from no version at all to proper versions, passing by
>> svn revisions, dates, or a mix of all.
>>
>> In Composer [1] we try to parse all that using ReflectionExtension, to
>> allow people to require some specific version of an extension if they
>> want. Obviously this doesn't work very well when no version or some
>> random revision number is provided.
>>
>> Is there any other way I overlooked to get more version info? If not,
>> can this at least be improved in the future?
> 
> For PECL extensions the version number should be fine (or you can hit
> the package maintainer ;-) ). For core stuff i'd propose to switch to
> PHP_VERSION as version everywhere. While this can be complicated for
> extensions which are maintained in both (oci8 for instance)

That sounds reasonable, but is it possible that someone does this for
all core ext (if it's not done yet, sorry I don't follow the commits
list)? Then I'll happily nag pecl maintainers if I find offenders :)

BTW I checked all the core exts I have on my machine, and none of them
has a version above 5, so changing them all to 5.4.2 should not mess up
any >=X.Y.Z constraint.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi