Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Re: PHP 5.2.5 Released - update on extensions versioning information »

Re: PHP 5.2.5 Released - update on extensions versioning information

php.internals

Gaetano Giunta

18 years ago
Hello everybody. I did a bit of analysis concerning the versioning information exposed by all extensions in 5.2.5 [the data in zend_module_entry, exposed to userland via phpversion()]. Extensions that do not expose any info at all: 46 out of 83 (the total number being calculated by counting the subdirs in /ext) Extensions that have had some changes in the source code since 5.2.4 and did not update their version info are, afaik: dom iconv json mysqli tidy (but at least the version info has been updated in the global phpinfo page) xmlreader xmlrpc Note that - mysql had some changes regarding compat with mysql 3. I am not sure if it only affects build time (in which case updating version info is useless) or not - oci extension ONLY updated version info (1.2.3 to 1.2.4) but NOT the code! The following extensions do not provide any version info, not even in the global phpinfo page: dbase gmp readline sysvsem sysvshm And last but not least, the list of extensions that do not provide version info in their zend_module_entry: bcmath bz2 calendar ctype curl dba dbase fdf frontbase ftp gd gettext gmp iconv imap interbase ldap libxml mbstring mcrypt mhash ming msql mssql ncurses odbc/birdstep openssl pcntl pcre pgsql posix pspell readline recode reflection session shmop snmp soap sockets sybase_db / sybase_ct sysvmsg sysvsem sysvshm wddx xml Bye Gaetano

Antony Dovgal

18 years ago
On 10.11.2007 22:19, Gaetano Giunta wrote:
> Hello everybody. > > I did a bit of analysis concerning the versioning information exposed by all extensions in 5.2.5 [the data in zend_module_entry, exposed to userland via phpversion()]. > > Extensions that do not expose any info at all: 46 out of 83 (the total number being calculated by counting the subdirs in /ext) > > Extensions that have had some changes in the source code since 5.2.4 and did not update their version info are, afaik: > dom > iconv > json > mysqli > tidy (but at least the version info has been updated in the global phpinfo page) > xmlreader > xmlrpc > > Note that > - mysql had some changes regarding compat with mysql 3. I am not sure if it only affects build time (in which case updating version info is useless) or not > - oci extension ONLY updated version info (1.2.3 to 1.2.4) but NOT the code!
OCI8 is (still) a PECL extension, so it's release cycle is not synced with PHP. Actually, other PECL extensions should be released through PECL either, but for some reason most of the authors do not do it after the extensions have got into the core. Speaking of the versions, I believe core extensions should update their versions only after some major changes/additions, which rarely happen in a bugfix branch (if at all).
-- Wbr, Antony Dovgal

Gaetano Giunta

18 years ago
...
>> - oci extension ONLY updated version info (1.2.3 to 1.2.4) but NOT the code! >> > > OCI8 is (still) a PECL extension, so it's release cycle is not synced with PHP. >
Yes I know. We have been testing recent versions a quite bit lately because of a strange problem with cursors remaining open (happens when the oracle server is windows and oci client is > 1.2.2). But if the oci8 code that was released as part of php 5.2.4 is exactly the same as what is found in pecl version 1.2.4, leaving it tagged "1.2.3" is a bit misleading. Checking dates, pecl 1.2.4 was released the day after php 5.2.4. I do not need to scan this list's archives to be sure that everybody involved in the oci code knew quite well about the pending release of php, and changing that single line of oci code where the version is stored would not have been a huge deal. If there really was no certainty that the php code would end up being the same as pecl 1.2.4, it could have been tagged 1.2.4-dev or something like that... Please note that I did not intend to single out oci coders as the bad guys: I am actually quite happy that at least the oci extension gets some version info at all!
> Actually, other PECL extensions should be released through PECL either, but for some > reason most of the authors do not do it after the extensions have got into the core. > > Speaking of the versions, I believe core extensions should update their versions > only after some major changes/additions, which rarely happen in a bugfix branch (if at all)
There are 2 problems with this, imho: 1 - sometimes extensions get moved out of core into pecl (such as... oci? ;) 2 - it is possible on unix to either upgrade or downgrade at will a single extension buy just recompiling it. I am not suggesting that it always makes sense or that lots of people do it, but it is possible, and makes any check-for-presence-of-a-given-bug that depends only on the php version much less reliable. People on windows can also do it without even recompiling, by just swapping the dlls, provided they can find the version they want on pecl4win or from other places. plus a 3 numbered version is very easy to assign to a lib (you know, like a new param for a function bumps up the middle number, a fix - any fix - bumps up the rightmost one etc... ) , and every single coder on earth is bound to understand it at first look... But maybe I misunderstood the meaning of "core" above for "bundled"... Bye Gaetano PS: I forgot in my previous mail: CONGRATS FOR THE NEW RELEASE!!!

Antony Dovgal

18 years ago
On 10.11.2007 23:32, Gaetano Giunta wrote:
> Checking dates, pecl 1.2.4 was released the day after php 5.2.4.
As I've already said, OCI8 and PHP releases are not synced.
> I do not need to scan this list's archives to be sure that everybody involved > in the oci code knew quite well about the pending release of php, and > changing that single line of oci code where the version is stored would > not have been a huge deal. If there really was no certainty that the php > code would end up being the same as pecl 1.2.4, it could have been > tagged 1.2.4-dev or something like that...
I don't understand what you're trying to say. Do you mean that all PECL maintainers should update their extensions before PHP release?
> plus a 3 numbered version is very easy to assign to a lib (you know, > like a new param for a function bumps up the middle number, a fix - any > fix - bumps up the rightmost one etc... )
That is what $Revision$ CVS tag does, version number is totally different thing IMO.
-- Wbr, Antony Dovgal

Gaetano Giunta

18 years ago
>> plus a 3 numbered version is very easy to assign to a lib (you know, >> like a new param for a function bumps up the middle number, a fix - any >> fix - bumps up the rightmost one etc... ) >> > > That is what $Revision$ CVS tag does, version number is totally different thing IMO. >
Sorry, but I disagree on this one. You might either think that an extension "version" defines either its api as accessible by the php kernel or as accessible by the php coder, but that's exactly what version numbers are used for. The cvs tag is for people that compile from source and have to report an error against a a specific version.

Ilia A.

18 years ago
The extensions rarely expose internal API, some certainly do offer a few PHPAPI functions, but that's more an exception then the rule. As far as the user functionality, you raise a good point, but many core extensions rarely change to warrant a new version token on every release. On 10-Nov-07, at 4:34 PM, Gaetano Giunta wrote:
> >>> plus a 3 numbered version is very easy to assign to a lib (you >>> know, like a new param for a function bumps up the middle number, >>> a fix - any fix - bumps up the rightmost one etc... ) >> >> That is what $Revision$ CVS tag does, version number is totally >> different thing IMO. >> > Sorry, but I disagree on this one. You might either think that an > extension "version" defines either its api as accessible by the php > kernel or as accessible by the php coder, but that's exactly what > version numbers are used for. > The cvs tag is for people that compile from source and have to > report an error against a a specific version. >
Ilia Alshanetsky

Lukas Kahwe Smith

18 years ago
On 10.11.2007, at 22:34, Gaetano Giunta wrote:
> >>> plus a 3 numbered version is very easy to assign to a lib (you >>> know, like a new param for a function bumps up the middle number, >>> a fix - any fix - bumps up the rightmost one etc... ) >> >> That is what $Revision$ CVS tag does, version number is totally >> different thing IMO. >> > Sorry, but I disagree on this one. You might either think that an > extension "version" defines either its api as accessible by the php > kernel or as accessible by the php coder, but that's exactly what > version numbers are used for. > The cvs tag is for people that compile from source and have to > report an error against a a specific version. >
I really think that PECL <-> Core relations and generally extension versioning should be very high up on our agenda. Ideally someone like you Tony, who actively maintains an extension both in PECL and core, would write up a proposal (I can do the wording if you provide me with the necessary content). This way we would have a discussion basis. Alternatively/in parallel maybe the people meeting in Paris could sit down and talk this item over a bit?!? regards, Lukas