FAQ
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

Search Discussions

  • Antony Dovgal at Nov 10, 2007 at 7:52 pm

    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 at Nov 10, 2007 at 8:33 pm
    ...
    - 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 at Nov 10, 2007 at 8:55 pm

    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 at Nov 10, 2007 at 9:34 pm

    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 at Nov 11, 2007 at 1:43 pm
    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 at Nov 19, 2007 at 12:49 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 10, '07 at 7:19p
activeNov 19, '07 at 12:49p
posts7
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase