hi,
We tried that many times but we fail to handle the version of bundled
extensions.
Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.
What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?
For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).
Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.
Thoughts?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
--
Big +1 for this! It would certainly make things less confusing for many
people.
--Kris
hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
What do you mean external version?
I don't have a problem with extensions having different versions
depending how they are installed.
Chris
On Wed, Apr 15, 2015 at 10:51 AM, christopher jones
christopher.jones@oracle.com wrote:
hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
What do you mean external version?
Too many "versions" :) installed not using the core sources but
github, pecl, whatever.
I don't have a problem with extensions having different versions
depending how they are installed.
Cheers,
Pierre
On Wed, Apr 15, 2015 at 10:51 AM, christopher jones
christopher.jones@oracle.com wrote:hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
What do you mean external version?
Too many "versions" :) installed not using the core sources but
github, pecl, whatever.I don't have a problem with extensions having different versions
depending how they are installed.Cheers,
Pierre
What I really meant to ask was about your proposed numbering scheme
(or #ifdefs or whatever) for versioning of external packages. (I read
"external version" as "version of the external package"). Subsequent
emails in the thread answered this.
Chris
On Apr 16, 2015 6:23 AM, "christopher jones" christopher.jones@oracle.com
wrote:
On Wed, Apr 15, 2015 at 10:51 AM, christopher jones
christopher.jones@oracle.com wrote:hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
What do you mean external version?
Too many "versions" :) installed not using the core sources but
github, pecl, whatever.I don't have a problem with extensions having different versions
depending how they are installed.Cheers,
PierreWhat I really meant to ask was about your proposed numbering scheme
(or #ifdefs or whatever) for versioning of external packages. (I read
"external version" as "version of the external package"). Subsequent
emails in the thread answered this.
And sounds good to you?
Hey：
Sent from my iPhone
hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?
in generally, I am +1 on this
I was also thinking of this yesterday, but the problem with opcache is:
We already release pecl opcache with version 7.0.X
If we now use Php version instead, then use may be confused with the versions?
Anyway, I still +1 on this
Thanks
For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Le 15/04/2015 07:08, Xinchen Hui a écrit :
Hey：
Sent from my iPhone
hi,
We tried that many times but we fail to handle the version of bundled
extensions.Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?
in generally, I am +1 on thisI was also thinking of this yesterday, but the problem with opcache is:
We already release pecl opcache with version 7.0.X
If we now use Php version instead, then use may be confused with the versions?
Anyway, I still +1 on this
I'm mostly +1 on this proposal.
Of course extension (like oci8) should be able to keep its version (when
it is correctly managed).
Yes opcache have an issue... so we probably have to keep 7.0.x until PHP 7.1
Most of the others extensions in php-src, version is just a mess.
Ex: SPL version 0.2 ? really ? ;)
Remi.
Thanks
For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.Thoughts?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
, I still +1 on this
I'm mostly +1 on this proposal.
Of course extension (like oci8) should be able to keep its version (when
it is correctly managed).Yes opcache have an issue... so we probably have to keep 7.0.x until PHP
7.1Most of the others extensions in php-src, version is just a mess.
Ex: SPL version 0.2 ? really ? ;)
Indeed, for well managed extensions (zip, opcache or timezone f.e.) there
is no need to change anything.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 15/04/2015 11:47, Pierre Joye a écrit :
On Apr 15, 2015 4:12 PM, "Remi Collet" remi@fedoraproject.org
wrote: , I still +1 on thisI'm mostly +1 on this proposal.
Of course extension (like oci8) should be able to keep its
version (when it is correctly managed).Yes opcache have an issue... so we probably have to keep 7.0.x
until PHP
7.1Most of the others extensions in php-src, version is just a
mess. Ex: SPL version 0.2 ? really ? ;)Indeed, for well managed extensions (zip, opcache or timezone f.e.)
there is no need to change anything.
So, the "mostly" was because of this.
So, now, all seems clear and big +1 from me.
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlUvyv4ACgkQYUppBSnxahjV2ACff5YyVfVVxQLFsAmQ/ztBd+Ol
4kYAnjAp8WskpkdRUOlBtikDd51bgD1E
=dUQZ
-----END PGP SIGNATURE
De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?
As the idea is that extensions available externally are supposed to change more often than the bundled version, why wouldn't we add a fourth number to their version ? By definition, version X.Y.Z.0 would correspond to the version distributed with PHP X.Y.Z.
Also :
-
When we distribute the same extension code with PHP 5.4, 5.5, and 5.6, what is the version we set for this code in pecl ? Will we have to create 3 branches, just for versions ?
-
If a new PHP version is released, do we need to change the extension version even if the code was not modified ?
Regards
François
De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?As the idea is that extensions available externally are supposed to
change more often than the bundled version, why wouldn't we add a fourth
number to their version ? By definition, version X.Y.Z.0 would correspond
to the version distributed with PHP X.Y.Z.
Again, if an extension is bundled and released outside, it should be
updated to match the version used for the external release, same code base,
same version. No need to over complicate it.
Also :
When we distribute the same extension code with PHP 5.4, 5.5, and 5.6,
what is the version we set for this code in pecl ? Will we have to create 3
branches, just for versions ?If a new PHP version is released, do we need to change the extension
version even if the code was not modified ?Regards
François
On Wed, Apr 15, 2015 at 1:01 PM, François Laupretre francois@php.net
wrote:
De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?As the idea is that extensions available externally are supposed to change
more often than the bundled version, why wouldn't we add a fourth number to
their version ? By definition, version X.Y.Z.0 would correspond to the
version distributed with PHP X.Y.Z.
But its not clear if this makes sense. if you have extension "foo" in php
7.0.1 and 7.0.2 and you want to provide an override via pecl, would you
need to release 7.0.1.1 and 7.0.2.1? That doesnt make sense imho.
Its either PHP Version == Ext Version or Ext has its own version. By
default it should be the first, but some maintainers could deviate if they
wish.
Also :
When we distribute the same extension code with PHP 5.4, 5.5, and 5.6,
what is the version we set for this code in pecl ? Will we have to create 3
branches, just for versions ?If a new PHP version is released, do we need to change the extension
version even if the code was not modified ?Regards
François
Again, take #3, ext released in and outiside the core will use the external
version number everywhere. Like oci, zip and other well managed versions.
The stupid think like 0.1 since 8 years will use the php version. That is
all.
Installer can easily knows which uses what.
Or am I missing something obvious?
On Wed, Apr 15, 2015 at 1:01 PM, François Laupretre francois@php.net
wrote:De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?As the idea is that extensions available externally are supposed to
change more often than the bundled version, why wouldn't we add a fourth
number to their version ? By definition, version X.Y.Z.0 would correspond
to the version distributed with PHP X.Y.Z.But its not clear if this makes sense. if you have extension "foo" in php
7.0.1 and 7.0.2 and you want to provide an override via pecl, would you
need to release 7.0.1.1 and 7.0.2.1? That doesnt make sense imho.Its either PHP Version == Ext Version or Ext has its own version. By
default it should be the first, but some maintainers could deviate if they
wish.Also :
When we distribute the same extension code with PHP 5.4, 5.5, and 5.6,
what is the version we set for this code in pecl ? Will we have to create 3
branches, just for versions ?If a new PHP version is released, do we need to change the extension
version even if the code was not modified ?Regards
François
De : Pierre Joye [mailto:pierre.php@gmail.com]
Again, take #3, ext released in and outiside the core will use the external version number everywhere. Like oci, zip and other well managed versions.
The stupid think like 0.1 since 8 years will use the php version. That is all.Or am I missing something obvious?
No, I just didn't understand you were just talking about extensions not released outside of the core distrib.
So, I am adapting my questions :) :
-
When we distribute the same extension code in more than one PHP release, which version do we set for this extension ? Do we set a different version for the same code in each release ?
-
If a new PHP version is released, do we need to change the extension version even if the code was not modified ?
Regards
François
On Wed, Apr 15, 2015 at 9:07 AM, François Laupretre francois@php.net
wrote:
De : Pierre Joye [mailto:pierre.php@gmail.com]
Again, take #3, ext released in and outiside the core will use the
external version number everywhere. Like oci, zip and other well managed
versions.
The stupid think like 0.1 since 8 years will use the php version. That
is all.Or am I missing something obvious?
No, I just didn't understand you were just talking about extensions not
released outside of the core distrib.So, I am adapting my questions :) :
- When we distribute the same extension code in more than one PHP release,
which version do we set for this extension ? Do we set a different version
for the same code in each release ?
I would like to see the numbers representative of changes. In that light,
the version number should change, because its a new "package" even if the
same code. The main I think it should change, is because many of the
distros don't "include" all the core extensions (for example, installing
php from apt-get in ubuntu 14.04 installs 5.5 but not with ZendOptimizer)
and these extensions are separate install. As such, it would be easier to
make sure you have the right things, if the versions are more specific (as
per the original post in the thread).
- If a new PHP version is released, do we need to change the extension
version even if the code was not modified ?Regards
François
--
- Ryan
De : Pierre Joye [mailto:pierre.php@gmail.com]
Again, take #3, ext released in and outiside the core will use the
external version number everywhere. Like oci, zip and other well managed
versions.
The stupid think like 0.1 since 8 years will use the php version. That
is all.Or am I missing something obvious?
No, I just didn't understand you were just talking about extensions not
released outside of the core distrib.So, I am adapting my questions :) :
When we distribute the same extension code in more than one PHP
release, which version do we set for this extension ? Do we set a different
version for the same code in each release ?If a new PHP version is released, do we need to change the extension
version even if the code was not modified ?
Good extensions synchronize core and external releases. For example, by the
time 5.6.8 is released, the codebase matches 1.3.4 for the external
release. That will be the version exposed for the core.
The problem we have now is core extensions with senseless versions without
any external versions. Or mixed codebase, like core is a mix of external
and core specific codes which is not in any external releases. That is what
we should solve.
De : Pierre Joye [mailto:pierre.php@gmail.com]
The problem we have now is core extensions with senseless versions
without
any external versions. Or mixed codebase, like core is a mix of external
and core specific codes which is not in any external releases. That is what
we should solve.
Do you have a list of these problematic extensions ?
François
De : Pierre Joye [mailto:pierre.php@gmail.com]
The problem we have now is core extensions with senseless versions
without
any external versions. Or mixed codebase, like core is a mix of external
and core specific codes which is not in any external releases. That is what
we should solve.Do you have a list of these problematic extensions ?
Core : 5.6.7-1~dotdeb.2
date : 5.6.7-1~dotdeb.2
ereg :
libxml :
openssl :
pcre :
zlib : 2.0
bcmath :
bz2 :
calendar :
ctype :
dba :
dom : 20031129
hash : 1.0
fileinfo : 1.0.5
filter : 0.11.0
ftp :
gettext :
SPL : 0.2
iconv :
json : 1.2.1
mbstring :
pcntl :
session :
standard : 5.6.7-1~dotdeb.2
posix :
Reflection : $Id: eff8bdc65b0beaf8f4ade6f06f848e6d43dfd826 $
Phar : 2.0.2
shmop :
SimpleXML : 0.1
soap :
sockets :
exif : 1.4 $Id: 5504545b9be3379c5244b371d825eb64659eb5f5 $
sysvmsg :
sysvsem :
sysvshm :
tokenizer : 0.1
wddx :
xml :
xmlreader : 0.1
xmlwriter : 0.1
zip : 1.12.4
mysqlnd : mysqlnd 5.0.11-dev - 20120503 - $Id:
3c688b6bbc30d36af3ac34fdd4b7b5b787fe5555 $
PDO : 1.0.4dev
curl :
mysql : 1.0
mysqli : 0.1
pdo_mysql : 1.0.2
mhash :
use:
<?php
$exts = get_loaded_extensions();
print_r($exts);
foreach ($exts as $ext) {
$r = new ReflectionExtension($ext);
echo "$ext : " . $r->getVersion() . "\n";
}
As you can see, quite unreliable as of now.
--
Pierre
@pierrejoye | http://www.libgd.org
Hi,
On Thu, Apr 16, 2015 at 6:27 PM, François Laupretre francois@php.net
wrote:De : Pierre Joye [mailto:pierre.php@gmail.com]
The problem we have now is core extensions with senseless versions
without
any external versions. Or mixed codebase, like core is a mix of external
and core specific codes which is not in any external releases. That is
what
we should solve.Do you have a list of these problematic extensions ?
json : 1.2.1
I bumped json to 1.4.0 some time ago and I would like to have its own
version as well. The reason is that after releasing PHP 7 I plan to release
jsond pecl ext for PHP 5 that will be drop in alternative for the existing
json in 5 and will behave exactly as json in 7. They will both have the
same major and minor. It will be also useful for other things to maintain
that versioning.
Cheers
Jakub
Since I'm working on something related... what's the verdict here? :)
Hi,
On Thu, Apr 16, 2015 at 6:27 PM, François Laupretre francois@php.net
wrote:De : Pierre Joye [mailto:pierre.php@gmail.com]
The problem we have now is core extensions with senseless versions
without
any external versions. Or mixed codebase, like core is a mix of external
and core specific codes which is not in any external releases. That is
what
we should solve.Do you have a list of these problematic extensions ?
json : 1.2.1
I bumped json to 1.4.0 some time ago and I would like to have its own
version as well. The reason is that after releasing PHP 7 I plan to release
jsond pecl ext for PHP 5 that will be drop in alternative for the existing
json in 5 and will behave exactly as json in 7. They will both have the
same major and minor. It will be also useful for other things to maintain
that versioning.Cheers
Jakub