Core extension versions

12 years ago by Anatol Belski — view source — reply

unread

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

ext/simplexml
"0.1"

ext/bz2
NO_VERSION_YET (== NULL) but was PECL 1.0 in 2003

ext/pdo
"1.0.4dev" whereby it was PECL 1.0.3 in 2006

and the winner might be that from ext/tokenizer

"0.1", /* Replace with version number for your extension */

as if it were just generated :)

Only a few extensions, just to name some - zip, dom, oci8, track the
version number.

Actually that doesn't look solid for the extensions being in the core
for years. And while that's a minor issue, it doesn't really smell good.
So, do we wanna do something about it?

Regards

Anatol

12 years ago by Michael Wallner — view source — reply

unread

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

ext/simplexml
"0.1"

ext/bz2
NO_VERSION_YET (== NULL) but was PECL 1.0 in 2003

ext/pdo
"1.0.4dev" whereby it was PECL 1.0.3 in 2006

and the winner might be that from ext/tokenizer

"0.1", /* Replace with version number for your extension */

as if it were just generated :)

Only a few extensions, just to name some - zip, dom, oci8, track the
version number.

Actually that doesn't look solid for the extensions being in the core
for years. And while that's a minor issue, it doesn't really smell good.
So, do we wanna do something about it?

I'd use PHP_VERSION for those extensions not explicitely managing a version.

--
Regards,
Mike

12 years ago by Pierre Joye — view source — reply

unread

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

ext/simplexml
"0.1"

ext/bz2
NO_VERSION_YET (== NULL) but was PECL 1.0 in 2003

ext/pdo
"1.0.4dev" whereby it was PECL 1.0.3 in 2006

and the winner might be that from ext/tokenizer

"0.1", /* Replace with version number for your extension */

as if it were just generated :)

Only a few extensions, just to name some - zip, dom, oci8, track the
version number.

Actually that doesn't look solid for the extensions being in the core
for years. And while that's a minor issue, it doesn't really smell good.
So, do we wanna do something about it?

I'd use PHP_VERSION for those extensions not explicitely managing a version.

--
Regards,
Mike

--

PHP_VERSION-bundle

for clarity in bug report :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

12 years ago by Christopher Jones — view source — reply

unread

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

I'd use PHP_VERSION for those extensions not explicitely managing a version.

PHP_VERSION-bundle

for clarity in bug report :)

For ext/* that do not (or no longer) have PECL releases (e.g. pdo,
dom) I would change their versions to PHP_VERSION-bundle even if they
currently have some rational versioning.

Extensions like ext/oci8 that historically do also have PECL releases
should manage their own version numbers

Chris

--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

12 years ago by Pierre Joye — view source — reply

unread

On Oct 15, 2013 6:13 PM, "Christopher Jones" christopher.jones@oracle.com
wrote:

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

I'd use PHP_VERSION for those extensions not explicitely managing a
version.

PHP_VERSION-bundle

for clarity in bug report :)

For ext/* that do not (or no longer) have PECL releases (e.g. pdo,
dom) I would change their versions to PHP_VERSION-bundle even if they
currently have some rational versioning.

Extensions like ext/oci8 that historically do also have PECL releases
should manage their own version numbers

Yes, that's the idea

12 years ago by Michael Wallner — view source — reply

unread

On Oct 15, 2013 6:13 PM, "Christopher Jones" christopher.jones@oracle.com
wrote:

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

I'd use PHP_VERSION for those extensions not explicitely managing a
version.

PHP_VERSION-bundle

for clarity in bug report :)

For ext/* that do not (or no longer) have PECL releases (e.g. pdo,
dom) I would change their versions to PHP_VERSION-bundle even if they
currently have some rational versioning.

Extensions like ext/oci8 that historically do also have PECL releases
should manage their own version numbers

Yes, that's the idea

--
Regards,
Mike

12 years ago by Marc Bennewitz — view source — reply

unread

Am 15.10.2013 18:12, schrieb Christopher Jones:

Hi,

as part of the extension version check on PECL it turned out, that the
extensions in the core are almost completely out of track with their
versions, not even to talk about version macros names. That regards to
exts imported from PECL as well as to the exts never been in PECL. Here
are a few examples of zend_module_entry version strings:

I'd use PHP_VERSION for those extensions not explicitely managing a
version.

PHP_VERSION-bundle

for clarity in bug report :)

For ext/* that do not (or no longer) have PECL releases (e.g. pdo,
dom) I would change their versions to PHP_VERSION-bundle even if they
currently have some rational versioning.

Extensions like ext/oci8 that historically do also have PECL releases
should manage their own version numbers

What about pecl extensions with version numbers grater than PHP_VERSION
on moving/moved to core? Don't know if this is the case somewhere.

Marc

12 years ago by Pierre Joye — view source — reply

unread

What about pecl extensions with version numbers grater than PHP_VERSION
on moving/moved to core? Don't know if this is the case somewhere.

Still released in pecl as well: package version (like oci or zip)
Only maintained in core: php-version-bundle

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

12 years ago by Marc Bennewitz — view source — reply

unread

Am 16.10.2013 20:32, schrieb Pierre Joye:

What about pecl extensions with version numbers grater than PHP_VERSION
on moving/moved to core? Don't know if this is the case somewhere.

Still released in pecl as well: package version (like oci or zip)
Only maintained in core: php-version-bundle

We had and we'll have pecl extensions that can be moved to core without
maintaining pecl releases after moving.

e.g:
You had the versions in pecl ..., 5.6, 5.6, 6.0, 6.1 and the extension
will be moved to PHP core in version 5.6 applications get in trouble as
it looks like an old version is installed.

In this case we could use the version before and increase it with the
same version PHP was increased by. (In the example above it would be 6.2)

Greetings

12 years ago by Pierre Joye — view source — reply

unread

Am 16.10.2013 20:32, schrieb Pierre Joye:

What about pecl extensions with version numbers grater than PHP_VERSION
on moving/moved to core? Don't know if this is the case somewhere.

Still released in pecl as well: package version (like oci or zip)
Only maintained in core: php-version-bundle

We had and we'll have pecl extensions that can be moved to core without
maintaining pecl releases after moving.

e.g:
You had the versions in pecl ..., 5.6, 5.6, 6.0, 6.1 and the extension
will be moved to PHP core in version 5.6 applications get in trouble as
it looks like an old version is installed.

In this case we could use the version before and increase it with the
same version PHP was increased by. (In the example above it would be 6.2)

those are either maintained and alive, or superseded/not maintained/not release.

If they are maintained and got releases then they will get a pecl
version, as usual.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org