Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32959
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.251 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=nt5KIEXAjd2BIrIQLU4vyi32iQKq3mSCQPp+37tuIa1r0F+O9ShyFbWDk3WT5zjnUDwZ/g4fHvdZ1Wv7+1whvHZYK989jfVG+dw2UZOEHNARIz5rcznUnNSoKI7FJ//gDMrIg36NPfllCs9sqmJGz2ySKRpvzqTa8Radwig0PqQ=
Message-ID: <471F10FE.1030209@gmail.com>
Date: Wed, 24 Oct 2007 11:31:42 +0200
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To:  internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Req: add versioning information to ALL php extensions
From: giunta.gaetano@gmail.com (Gaetano Giunta)

Hello everybody.

I just stumbled on an oci bug (piecewise saving data to lobs eats one 
char for every piece) that has been fixed in the pecl version of the oci 
extension, starting from rev. 1.0, and in the bundled php extension, 
starting with php 5.1.6.

Needless to say, the only way to code around this bug is to either test 
for it or grep through phpinfo() for specific oci version strings (since 
the current php install might be using the bundled oci ext or not). Oh, 
and the fix was never announced in either the pecl or php changelogs...

In the past I have come across similar situations with xmlrpc and json 
extensions changing their apis or simply fixing their bugs in a way that 
makes php library writers want to pull their hair out.

Yesterday I dug out in the php manual and code, and found out that the 
phpversion() php function in fact looks like it was designed from the 
ground up to give coders an exact version number of every single 
extension in use, be it from pecl, php or anywhere else.

It just needs extension maintainers to kindly put a meaningful version 
string - any will do - in their zend_module_entry structure, instead of 
NO_VERSION_YET.

It does not look like a huge amount of work to me, so I really am 
wondering what I am missing here... maybe a formal declaration from the 
core devs that extensions not providing a version info will not be 
accepted anymore, starting NOW?

Thanks
Gaetano Giunta