Grokbase › Groups › PHP › php-internals › October 2013
FAQ
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

Search Discussions

  • Michael Wallner at Oct 15, 2013 at 3:20 pm ⇧

    On 15 October 2013 17:16, Anatol Belski 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:

    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
  • Pierre Joye at Oct 15, 2013 at 3:45 pm ⇧

    On Tue, Oct 15, 2013 at 5:19 PM, Michael Wallner wrote:
    On 15 October 2013 17:16, Anatol Belski 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:

    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 Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    PHP_VERSION-bundle

    for clarity in bug report :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Christopher Jones at Oct 15, 2013 at 4:12 pm ⇧

    On 10/15/13 8:45 AM, Pierre Joye wrote:
    On Tue, Oct 15, 2013 at 5:19 PM, Michael Wallner wrote:
    On 15 October 2013 17:16, Anatol Belski 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

    Chris
  • Pierre Joye at Oct 15, 2013 at 4:33 pm ⇧

    On Oct 15, 2013 6:13 PM, "Christopher Jones" wrote:

    On 10/15/13 8:45 AM, Pierre Joye wrote:
    On Tue, Oct 15, 2013 at 5:19 PM, Michael Wallner wrote:
    On 15 October 2013 17:16, Anatol Belski 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
  • Michael Wallner at Oct 15, 2013 at 6:24 pm ⇧

    On 15 October 2013 18:33, Pierre Joye wrote:
    On Oct 15, 2013 6:13 PM, "Christopher Jones" wrote:


    On 10/15/13 8:45 AM, Pierre Joye wrote:
    On Tue, Oct 15, 2013 at 5:19 PM, Michael Wallner wrote:
    On 15 October 2013 17:16, Anatol Belski 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
    +1

    --
    Regards,
    Mike
  • Marc Bennewitz at Oct 16, 2013 at 6:04 pm ⇧

    Am 15.10.2013 18:12, schrieb Christopher Jones:

    On 10/15/13 8:45 AM, Pierre Joye wrote:
    On Tue, Oct 15, 2013 at 5:19 PM, Michael Wallner wrote:
    On 15 October 2013 17:16, Anatol Belski 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
    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
  • Pierre Joye at Oct 16, 2013 at 6:32 pm ⇧

    On Wed, Oct 16, 2013 at 8:04 PM, Marc Bennewitz wrote:

    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,
  • Marc Bennewitz at Oct 16, 2013 at 7:06 pm ⇧

    Am 16.10.2013 20:32, schrieb Pierre Joye:
    On Wed, Oct 16, 2013 at 8:04 PM, Marc Bennewitz wrote:

    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
  • Pierre Joye at Oct 16, 2013 at 7:50 pm ⇧

    On Wed, Oct 16, 2013 at 9:06 PM, Marc Bennewitz wrote:

    Am 16.10.2013 20:32, schrieb Pierre Joye:
    On Wed, Oct 16, 2013 at 8:04 PM, Marc Bennewitz wrote:

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 15, '13 at 3:16p
activeOct 16, '13 at 7:50p
posts10
users5
websitephp.net

5 users in discussion

Pierre Joye: 4 posts Michael Wallner: 2 posts Marc Bennewitz: 2 posts Christopher Jones: 1 post Anatol Belski: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase