Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.
This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.
Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
- ??
I obviously will help porting some of them.
Julien.P
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
- ??
I obviously will help porting some of them.
Julien.P
hi,
here are some download stats for the pecl packages (ofc. only counting the
packages which are installed via pecl install, but still a good start):
http://pecl.php.net/package-stats.php
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]
Sent: Wednesday, January 14, 2015 10:16 AM
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.hi,
here are some download stats for the pecl packages (ofc. only counting
the packages which are installed via pecl install, but still a good
start):
http://pecl.php.net/package-stats.php
FYI, WinCache is released and downloaded primarily from SourceForge, and as a result the actual usage metrics are not captured on PECL package-stats.
I used the download reporting metrics tool in SourceForge, and WinCache had 306,564 downloads (all flavors) for 2014. For the past 5 years:
2014: 306,564
2013: 260,450
2012: 181,304
2011: 159,070
2010: 415,333
Total: 1,322,721
Thx!
--E.
I suppose http://pecl.php.net/package-stats.php could help there
Kind regards,
Wim
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
- ??
I obviously will help porting some of them.
Julien.P
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
Yes, actually I'm knee-deep in porting pecl_http.
After a quick glance at the PECL package stats (of packages wchich are
not already in kind of an exclusive/external maintainance status, and
which I used to use, so maybe biased):
- imagick
- uploadprogress
- geoip
- uuid (I could jump on this one actually...)
--
Regards,
Mike
Hi
After a quick glance at the PECL package stats (of packages wchich are
not already in kind of an exclusive/external maintainance status, and
which I used to use, so maybe biased):
- imagick
- uploadprogress
Isn't uploadprogress nowadays (since quite some time) possible with
standard PHP? I didn't much take care of that extension, because of no
more need for it. But I didn't use this feature since a long time, so I
don't know ;)
chregu
- geoip
- uuid (I could jump on this one actually...)
--
Liip AG // Limmatstrasse 183 // CH-8005 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x1575A89B
Hi
After a quick glance at the PECL package stats (of packages wchich are
not already in kind of an exclusive/external maintainance status, and
which I used to use, so maybe biased):
- imagick
- uploadprogress
Isn't uploadprogress nowadays (since quite some time) possible with
standard PHP? I didn't much take care of that extension, because of no
more need for it. But I didn't use this feature since a long time, so I
don't know ;)
I haven't done any frontend upload work for quite some time, and
actually used APC most of the time back then, but IIRC there's only the
session thing built into PHP, isn't it?
--
Regards,
Mike
- imagick
Most of the work was done while it was still called NG:
https://github.com/danack/imagick/tree/phpng . Which means that branch
probably won't work against master as there have been other small
changes.
btw It would be great if there was a single guide for a porting
extensions from 5.x to 7. I know the RFC had quite a bit of info in
it, but it wasn't that easy to read and there have been quite a few
other little changes since then.
Having a complete list in one place rather than having to figure what
needs to be done, would make extension maintainers lives be easier,
and help the migration to PHP 7.
cheers
Dan
- imagick
Most of the work was done while it was still called NG:
https://github.com/danack/imagick/tree/phpng . Which means that branch
probably won't work against master as there have been other small
changes.btw It would be great if there was a single guide for a porting
extensions from 5.x to 7. I know the RFC had quite a bit of info in
it, but it wasn't that easy to read and there have been quite a few
other little changes since then.Having a complete list in one place rather than having to figure what
needs to be done, would make extension maintainers lives be easier,
and help the migration to PHP 7.
The closest we have at this point is:
https://wiki.php.net/phpng-upgrading
I just updated it to reflect the current zend_string API and there are
probably a few more things that aren't completely up to date. If people
here could skim it and fix anything that isn't current it would help.
-Rasmus
The closest we have at this point is:
https://wiki.php.net/phpng-upgrading
If people
here could skim it and fix anything that isn't current it would help.
Thanks. I think the TSRM changes need to be added, which could be copied from:
https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f
Providing a link to a commit that implemented the TSRM changes for an
extension, so that people could see the actual changes needed, would
be awesome.
cheers
Dan
hi,
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
- ??
I obviously will help porting some of them.
I am not a big fan of such top lists as it covers only part of the needs.
More importantly, what's about the porting strategy?
New branch, #ifdef hell or separate files? Separate or common releases?
Using pickle, almost everything is possible from an install/update
point of view, support for install from VCS makes the new branch(es)
option easier too. However we have to define what we would prefer to
do.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hey:
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.Someone for a quick list ?
- Memcached
- Gearman
- Apcu
- http (Mike already did it ?)
- ??
I obviously will help porting some of them.
as I remembered, memcached and redis already be proted by demon at php.net
thanks
Julien.P
--
Xinchen Hui
@Laruence
http://www.laruence.com/
I obviously will help porting some of them.
as I remembered, memcached and redis already be proted by demon at php.net
For memcached, do you mean this pull request?
https://github.com/php-memcached-dev/php-memcached/pull/148
It looks pretty good. It is missing the zend_string changes for the INI
stuff, but that came after this was created. So probably a few other
small things to fix up. I thought for sure it would miss this:
- add_assoc_null_ex(return_value, mkeys[i], mkeys_len[i] + 1);
- add_assoc_null_ex(return_value, mkeys[i], mkeys_len[i]);
But it is in there. I hadn't noticed this pull request and had already
done most of it locally here. I'll merge the two.
-Rasmus
Hi,
Sorry for the late reply.
在 2015年1月15日 星期四，下午1:21，Rasmus Lerdorf 写道：
I obviously will help porting some of them.
as I remembered, memcached and redis already be proted by demon at php.net (http://php.net)
For memcached, do you mean this pull request?
https://github.com/php-memcached-dev/php-memcached/pull/148
Yes, this is the patch for the memcached extension to support php7, but
the last commit is on 29 Aug 2014, so it must have a lot of things need to
rewrite or fix up.
I’ll do finish the upgrade within a month.
It looks pretty good. It is missing the zend_string changes for the INI
stuff, but that came after this was created. So probably a few other
small things to fix up. I thought for sure it would miss this:
- add_assoc_null_ex(return_value, mkeys[i], mkeys_len[i] + 1);
- add_assoc_null_ex(return_value, mkeys[i], mkeys_len[i]);
But it is in there. I hadn't noticed this pull request and had already
done most of it locally here. I'll merge the two.-Rasmus
—
Wei Dai
@Demon
Julien Pauli in php.internals (Wed, 14 Jan 2015 18:53:10 +0100):
This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.
Some time ago I had a discussion with Mike Wallner and others about a
naming convention for php7/php5.x branches of extensions. It would be
easier to build a lot of extensions for PHP7 if most extension
maintainers used the same names.
See pecl-dev@lists.php.net/msg02585.html" rel="nofollow" target="_blank">https://www.mail-archive.com/pecl-dev@lists.php.net/msg02585.html
Brief summary:
Compiling for php7: use the phpng branch if it exists, otherwise master.
Compiling for php5.x: use the phpog branch if exists, otherwise master.
Michael used phpng for the php7 branch, but since that discussion I
already see other branch names pop up. I believe a branch 'next' was
introduced in opcache or some extension like that.
A 'Top 10 Pecl extensions PHP7 compatibility' should at least contain
the name of the PHP7 branch if that is not the master branch. And some
sort of consensus on the names of PHP7 and/or PHP5 branches would be
helpful.
Jan
Not sure how that helps, since you would tag versions anyways using semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve this.
Julien Pauli in php.internals (Wed, 14 Jan 2015 18:53:10 +0100):
This will allow more people to help testing both PHP7 (some people may
need
some of the top-10 pecl ext to run their apps) and those extensions.Some time ago I had a discussion with Mike Wallner and others about a
naming convention for php7/php5.x branches of extensions. It would be
easier to build a lot of extensions for PHP7 if most extension
maintainers used the same names.See pecl-dev@lists.php.net/msg02585.html" rel="nofollow" target="_blank">https://www.mail-archive.com/pecl-dev@lists.php.net/msg02585.html
Brief summary:
Compiling for php7: use the phpng branch if it exists, otherwise master.
Compiling for php5.x: use the phpog branch if exists, otherwise master.Michael used phpng for the php7 branch, but since that discussion I
already see other branch names pop up. I believe a branch 'next' was
introduced in opcache or some extension like that.A 'Top 10 Pecl extensions PHP7 compatibility' should at least contain
the name of the PHP7 branch if that is not the master branch. And some
sort of consensus on the names of PHP7 and/or PHP5 branches would be
helpful.Jan
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve this.
The branch name convention was meant for those developers that want to
maintain the same version for both PHP7 and PHP5.x. In thoese cases
there is no difference in version tags. Just a git checkout -b phpng if
you want the PHP7 branch.
See for instance
http://git.php.net/?p=pecl/http/pecl_http.git;a=shortlog;h=refs/heads/phpng
Jan
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using
semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve
this.The branch name convention was meant for those developers that want to
maintain the same version for both PHP7 and PHP5.x. In thoese cases
there is no difference in version tags. Just a git checkout -b phpng if
you want the PHP7 branch.
Oh ok my bad. I was under the impression this was for distro/packaging
reasons or something
as a convention.
See for instance
http://git.php.net/?p=pecl/http/pecl_http.git;a=shortlog;h=refs/heads/phpngJan
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using
semver,
so if there is a master vs next/phpng branch, then they might still
result
in two tags v1.0 and v2.0 and there is no way to automatically resolve
this.The branch name convention was meant for those developers that want to
maintain the same version for both PHP7 and PHP5.x. In thoese cases
there is no difference in version tags. Just a git checkout -b phpng if
you want the PHP7 branch.Oh ok my bad. I was under the impression this was for distro/packaging
reasons or something
as a convention.
Well there is a concern about packaging using this method. As of now it is
not possible to package them.
I tend to prefer separate files and add the right source at configure time.
It is then easier to keep fixes, features, etc. in sync.
However both solutions may work, if we decide to go for one or another
solution. We can add support for the packaging/install in pickle and the
website.
It is also important to note that I would like to push the usage of install
from git/other VCS in the near term, using pickle, and use the website only
for the meta info but not (or much less) for hosting the releases.
On Thu, Jan 15, 2015 at 4:11 PM, Jan Ehrhardt phpdev@ehrhardt.nl
wrote:Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using
semver,
so if there is a master vs next/phpng branch, then they might still
result
in two tags v1.0 and v2.0 and there is no way to automatically
resolve
this.The branch name convention was meant for those developers that want to
maintain the same version for both PHP7 and PHP5.x. In thoese cases
there is no difference in version tags. Just a git checkout -b phpng
if
you want the PHP7 branch.Oh ok my bad. I was under the impression this was for distro/packaging
reasons or something
as a convention.Well there is a concern about packaging using this method. As of now it
is not possible to package them.I tend to prefer separate files and add the right source at configure
time. It is then easier to keep fixes, features, etc. in sync.However both solutions may work, if we decide to go for one or another
solution. We can add support for the packaging/install in pickle and the
website.It is also important to note that I would like to push the usage of
install from git/other VCS in the near term, using pickle, and use the
website only for the meta info but not (or much less) for hosting the
releases.
Also using branches may be an issue too with semantic versions, for the
version names, using composer-like tags/branch fetch.
It is also important to note that I would like to push the usage of install
from git/other VCS in the near term, using pickle, and use the website only
for the meta info but not (or much less) for hosting the releases.
As well as that, I think more of the ecosystem of extensions needs to
be thought about, in particular where the issue tracker for extensions
lives. Although it made sense in the past to have all issues tracked
on bugs.php.net (due to the difficulty of hosting an issue tracker) it
is not optimal now, and has a couple of problems.
i) Because the issues are away from the code repository, it's far
harder for people to contribute to extensions that it would be if
everything is in one place.
It's also difficult for people to make a code fix in their own fork
and let other people be aware that the fix exists and use it. This is
obviously much easier on Github where the entry barrier to commenting
on issues is much lower, as well the barrier to making your code
available to other people.
This would be very useful where the alledged maintainers of an
extension are no longer responding to emails.
ii) Most of the issues related to a particular PECL package can only
be handled by someone who is actively maintaining the extension. For
example, the Gearman extension is a relatively modern extension that
is actively maintained and yet still has 21 open issues, some dating
back years.
Having those issues open in the PHP bug tracker rather than in the
Gearman repository on Github does not help anyone, and just clogs up
the PHP bug tracker with items that PHP developers can't help with.
A couple of examples of other PECL extensions:
https://bugs.php.net/bug.php?id=66194
https://bugs.php.net/bug.php?id=59171
It's a waste of time having these things open in bugs.php.net. I think
it would be better to require extensions that don't ship as part of
the PHP official packages to have their issues hosted elsewhere -
which would probably be Github for the majority of extensions.
Changing the ecosystem shouldn't be a decision rushed into, but it
would be good to think about how to make it better.
cheers
Dan
It is also important to note that I would like to push the usage of install
from git/other VCS in the near term, using pickle, and use the website only
for the meta info but not (or much less) for hosting the releases.As well as that, I think more of the ecosystem of extensions needs to
be thought about, in particular where the issue tracker for extensions
lives. Although it made sense in the past to have all issues tracked
on bugs.php.net (due to the difficulty of hosting an issue tracker) it
is not optimal now, and has a couple of problems.i) Because the issues are away from the code repository, it's far
harder for people to contribute to extensions that it would be if
everything is in one place.It's also difficult for people to make a code fix in their own fork
and let other people be aware that the fix exists and use it. This is
obviously much easier on Github where the entry barrier to commenting
on issues is much lower, as well the barrier to making your code
available to other people.This would be very useful where the alledged maintainers of an
extension are no longer responding to emails.ii) Most of the issues related to a particular PECL package can only
be handled by someone who is actively maintaining the extension. For
example, the Gearman extension is a relatively modern extension that
is actively maintained and yet still has 21 open issues, some dating
back years.Having those issues open in the PHP bug tracker rather than in the
Gearman repository on Github does not help anyone, and just clogs up
the PHP bug tracker with items that PHP developers can't help with.A couple of examples of other PECL extensions:
https://bugs.php.net/bug.php?id=66194
https://bugs.php.net/bug.php?id=59171It's a waste of time having these things open in bugs.php.net. I think
it would be better to require extensions that don't ship as part of
the PHP official packages to have their issues hosted elsewhere -
which would probably be Github for the majority of extensions.Changing the ecosystem shouldn't be a decision rushed into, but it
would be good to think about how to make it better.
I mentioned that many times but I feel ike I will simply create a new
thread + wiki pages (RFC) to describe a possible roadmap.
But basically, I would really move pecl from a package hosting site to
a packagist like application. The new pickle tool, based on the same
concepts than composer, without requiring package.xml or multiple
definitions of the same meta info, supports all protocols composer
does, install/update from VCS included. That means there will be no
more requirement to actually create a release tgz, a simple tag will
be just fine.
For the issues tracker, I would rather leave it to the developers to
decide. In any case there is some work to do to make bugs.php.net
easier to deal with from a pecl pov.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve this.The branch name convention was meant for those developers that want to
maintain the same version for both PHP7 and PHP5.x. In thoese cases
there is no difference in version tags. Just a git checkout -b phpng if
you want the PHP7 branch.
I'll just write down my view of things here from a Composer
perspective, which is relevant assuming that eventually we'll get a
composer.json in extensions that would allow composer to "see"
extensions as packages and resolve them to an installable version
which pickle would then install.
The way I see it, the php5.x branch, no matter what it's called,
should require php 5.* in its composer.json, and it should for example
produce [1] releases in the 1.x range.
If you then make a php7-specific version, in that it does not compile
on php5 anymore, it can remain master or be a new branch it doesn't
matter so much but it should require php 7.0.* instead and start
producing 2.x releases because bumping your dependencies is a BC
break.
The way typical semver-abiding php projects would do this is to make
master the new 2.x producer and create a 1.x branch to keep
maintaining the 1.0 version.
If the master branch instead still compiles on php 5 AND 7 then it can
require "5.0 - 7.0" (equivalent to >= 5.0 and < 7.1) and keeps
producing 1.x releases.
It would be great to see pecl folks get more in line with semver and
using more normalized branch and tag names. I understand that pecl is
its own ecosystem and I come in out of nowhere and ask you to change,
but I really believe it's for the best in the longer term.
[1] in the sense that a branch produces releases since tags are made
out of a given branch usually.
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi