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
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
xmlrpcNote 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
...
- 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!!!
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
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.
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.
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
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