Heya,
It appears that many extensions do not expose proper version information.
Here an abstract of the various things I found using the following script:
$ for i in php -m; do php --re $i | grep "$i version"; done
curl <no_version>
date 5.4.0
dom 20031129
mysqlnd mysqlnd 5.0.10 - 20111026 - $Revision: 323634 $
PDO 1.0.4dev
Reflection $Revision: 321634 $
xdebug 2.2.0rc1
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?
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
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)
johannes
+1 for that notice.
In fact, Zend API provides extensions a char* to give a hint about the
extension version, but I guess no-one has been serious and really used that
field as it would have to be.
I recently noticed mistakes in ext/mysqlnd_ms as well.
I then agree with Johannes, just use PHP_VERSION, and you can think about
yourself as safe.
Well, at least until a curious setup would compile PHP itself mixing
extension versions in the same PHP Core version ...
Cheers
Julien.P
2012/4/23 Johannes Schlüter johannes@schlueters.de
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_VERSIONas version everywhere. While this can be complicated for
extensions which are maintained in both (oci8 for instance)johannes
In fact, Zend API provides extensions a char* to give a hint about the
extension version, but I guess no-one has been serious and really used
that field as it would have to be.
Every(*) PECL extension does.
(*) The exception proves the rule.
I recently noticed mistakes in ext/mysqlnd_ms as well.
Mistakes happen. For a version their was a mistake. For 10 other
releases it had the correct version number.
johannes
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_VERSIONas 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
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_VERSIONas 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.
dom has the version 20031129 which is greater than 5. Not sure if anyone
really checks against that, since not much changed there since obviously
2003 ;)
But the problem with extensions like dom is the used libxml version
which actually causes problems, not the version of the extension itself.
There's a bug in libxml < 2.7.0 which can hit you hard for certain
namespaces. So getting just the version number won't help you here.
But that's not something we have to take care of IMHO, one can get that
information with LIBXML_VERSION or LIBXML_DOTTED_VERSION
chregu
Cheers
--
Liip AG // Feldstrasse 133 // CH-8004 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE
dom has the version 20031129 which is greater than 5. Not sure if anyone
really checks against that, since not much changed there since obviously
2003 ;)
Yup it's the only one I noticed but since it's fairly well established,
usually you don't need to check if it's there (AFAIK).
But the problem with extensions like dom is the used libxml version
which actually causes problems, not the version of the extension itself.
There's a bug in libxml < 2.7.0 which can hit you hard for certain
namespaces. So getting just the version number won't help you here.But that's not something we have to take care of IMHO, one can get that
information withLIBXML_VERSIONorLIBXML_DOTTED_VERSION
True, and maybe we should actually expose libxml and other bundled libs
as packages too via Composer. Could be handy.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
dom has the version 20031129 which is greater than 5. Not sure if anyone
really checks against that, since not much changed there since obviously
2003 ;)Yup it's the only one I noticed but since it's fairly well established,
usually you don't need to check if it's there (AFAIK).But the problem with extensions like dom is the used libxml version
which actually causes problems, not the version of the extension itself.
There's a bug in libxml < 2.7.0 which can hit you hard for certain
namespaces. So getting just the version number won't help you here.But that's not something we have to take care of IMHO, one can get that
information withLIBXML_VERSIONorLIBXML_DOTTED_VERSIONTrue, and maybe we should actually expose libxml and other bundled libs
as packages too via Composer. Could be handy.
libxml isn't bundled.. That is why its often hard to understand why
stuff works on one server but not the other :)
For many extensions wrapping external libraries it is more useful to
know the version of that lib then the extension.
-Hannes