Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Remove deprecated functionality in PHP 7 »

[RFC] Remove deprecated functionality in PHP 7

php.internals

Nikita Popov

11 years ago
Hi internals! We currently have a number of deprecated features, which we likely want to remove in PHP 7. I've created a tracking RFC listing deprecated functionality (if I missed something, please tell): https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 I expect many of these are no-brainers (like assigning new by-reference), but other items like removal of ext/mysql may need additional consideration. Unless there are items that are particularly contested, I'd like to handle the bulk of these in a single vote and only have separate votes for ext/ereg and ext/mysql, as these are arguably more intrusive. Thanks, Nikita

Kris Craig

11 years ago
On Oct 11, 2014 1:52 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote:
> > Hi internals! > > We currently have a number of deprecated features, which we likely want to > remove in PHP 7. I've created a tracking RFC listing deprecated > functionality (if I missed something, please tell): > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > I expect many of these are no-brainers (like assigning new by-reference), > but other items like removal of ext/mysql may need additional
consideration.
> > Unless there are items that are particularly contested, I'd like to handle > the bulk of these in a single vote and only have separate votes for > ext/ereg and ext/mysql, as these are arguably more intrusive. > > Thanks, > Nikita
+1 on all of that. As far as ext/mysql is concerned, I would eagerly vote in favor of removing it. It performs poorly, is procedural, less secure, doesn't support prepared statements, etc. It's always annoyed me how sites like w3schools still teach people to use ext/mysql. It's been deprecated for quite awhile now and I think it's time to pull the plug on it. --Kris

Rasmus Lerdorf

11 years ago
> On Oct 11, 2014, at 16:47, Kris Craig <kris.craig@gmail.com> wrote: > >> On Oct 11, 2014 1:52 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote: >> >> Hi internals! >> >> We currently have a number of deprecated features, which we likely want to >> remove in PHP 7. I've created a tracking RFC listing deprecated >> functionality (if I missed something, please tell): >> >> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 >> >> I expect many of these are no-brainers (like assigning new by-reference), >> but other items like removal of ext/mysql may need additional > consideration. >> >> Unless there are items that are particularly contested, I'd like to handle >> the bulk of these in a single vote and only have separate votes for >> ext/ereg and ext/mysql, as these are arguably more intrusive. >> >> Thanks, >> Nikita > > +1 on all of that. > > As far as ext/mysql is concerned, I would eagerly vote in favor of removing > it. It performs poorly, is procedural, less secure, doesn't support > prepared statements, etc. > > It's always annoyed me how sites like w3schools still teach people to use > ext/mysql. It's been deprecated for quite awhile now and I think it's time > to pull the plug on it.
Keep in mind though that it would be mostly symbolic. The majority of users get their PHP and extensions from distros. And distros have been separating out core-bundled extensions for a decade now. Users have absolutely no idea whether their php-mysql package comes from core or from pecl, nor do they care. So, unbundling it on our side will have close to zero impact on its use. In fact, in a weird way it might actually help make people continue to use it because if we unbundle it and stick it in pecl we would obviously not have it spew out 'deprecated' notices like we do as of 5.5. I mean, we still could, of course, but it would be weird having a non-core pecl extension declare itself deprecated. I am not against unbundling it, I just don't think it will achieve what you hope it will. -Rasmus

Lester Caine

11 years ago
On 12/10/14 01:13, Rasmus Lerdorf wrote:
> Keep in mind though that it would be mostly symbolic. The majority of users get their PHP and extensions from distros. And distros have been separating out core-bundled extensions for a decade now. Users have absolutely no idea whether their php-mysql package comes from core or from pecl, nor do they care. So, unbundling it on our side will have close to zero impact on its use. In fact, in a weird way it might actually help make people continue to use it because if we unbundle it and stick it in pecl we would obviously not have it spew out 'deprecated' notices like we do as of 5.5. I mean, we still could, of course, but it would be weird having a non-core pecl extension declare itself deprecated. > > I am not against unbundling it, I just don't think it will achieve what you hope it will.
I may be wrong but certainly SUSE bundles mysql, mysqli and pdo_mysql in the one package and I think most do?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Dmitry Stogov

11 years ago
Note, that once we move extension outside of main source tree, only extension maintainers (if any) will support them. According to the voting process, I think it makes sense to vote for each feature separately. Thanks. Dmitry. On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Jan Ehrhardt

11 years ago
Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400):
>Note, that once we move extension outside of main source tree, only >extension maintainers (if any) will support them.
In the ext/mysql case this will be a bit uncomfortable. If you compile PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of the functionality of ext/mysql is used. What if mysqlnd drifts away from supporting ext/mysql? Jan

Pierre Joye

11 years ago
On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" <phpdev@ehrhardt.nl> wrote:
> > Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400): > >Note, that once we move extension outside of main source tree, only > >extension maintainers (if any) will support them. > > In the ext/mysql case this will be a bit uncomfortable. If you compile > PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of > the functionality of ext/mysql is used. What if mysqlnd drifts away from > supporting ext/mysql?
It is more the other way 'round. Mysql being not updated to support latest core change. Which may happen, and I would have no issue with that if we choose to remove it. Keeping in mind that we talk about 7 here. So users still have something like at least 3 years in front of them, 4 if we do a 5.7.

Jan Ehrhardt

11 years ago
Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
>On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" <phpdev@ehrhardt.nl> wrote: >> >> In the ext/mysql case this will be a bit uncomfortable. If you compile >> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of >> the functionality of ext/mysql is used. What if mysqlnd drifts away from >> supporting ext/mysql? > >It is more the other way 'round. > >Mysql being not updated to support latest core change. Which may happen, >and I would have no issue with that if we choose to remove it.
OK, maybe I should have said 'what if mysqlnd and ext/mysql drift apart?' But it still feels uncomfortable. Will it be considered a BC-break if, say, PHP 7.1 changes something in mysqlnd and ext/mysqli that is also being used by pecl/mysql? Jan

Pierre Joye

11 years ago
On Oct 13, 2014 8:08 PM, "Jan Ehrhardt" <phpdev@ehrhardt.nl> wrote:
> > Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200): > >On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" <phpdev@ehrhardt.nl> wrote: > >> > >> In the ext/mysql case this will be a bit uncomfortable. If you compile > >> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of > >> the functionality of ext/mysql is used. What if mysqlnd drifts away
from
> >> supporting ext/mysql? > > > >It is more the other way 'round. > > > >Mysql being not updated to support latest core change. Which may happen, > >and I would have no issue with that if we choose to remove it. > > OK, maybe I should have said 'what if mysqlnd and ext/mysql drift > apart?' But it still feels uncomfortable. Will it be considered a > BC-break if, say, PHP 7.1 changes something in mysqlnd and ext/mysqli > that is also being used by pecl/mysql?
Changes in core happens all the time. It is the responsibility of the external extension maintainers to update their code. That being said, having mysql in pecl should really not mean that its maintainers should keep it alive forever. Users willing (for whatever reasons) to keep using it, can keep using 5.x. But it is not our call, but the maintainers.

Johannes Schlüter

11 years ago
On Mon, 2014-10-13 at 14:10 +0200, Jan Ehrhardt wrote:
> In the ext/mysql case this will be a bit uncomfortable. If you compile > PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of > the functionality of ext/mysql is used. What if mysqlnd drifts away from > supporting ext/mysql?
Independently from moving ext/mysql to PECL or not I don't see this happen in the foreseeable future. I'm quite sure that as long as there are this huge number of forum posts, applications, ... using mysql_* this will be kept working. While I support anything teaching users of alternatives ... johannes (This is no legal commitment from Oracle or anything like that)

Derick Rethans

11 years ago
On Sat, 11 Oct 2014, Kris Craig wrote:
> On Oct 11, 2014 1:52 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote: > > > > We currently have a number of deprecated features, which we likely > > want to remove in PHP 7. I've created a tracking RFC listing > > deprecated functionality (if I missed something, please tell): > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > I expect many of these are no-brainers (like assigning new > > by-reference), but other items like removal of ext/mysql may need > > additional consideration. > > > > Unless there are items that are particularly contested, I'd like to > > handle the bulk of these in a single vote and only have separate > > votes for ext/ereg and ext/mysql, as these are arguably more > > intrusive. > > +1 on all of that. > > As far as ext/mysql is concerned, I would eagerly vote in favor of removing > it. It performs poorly, is procedural, less secure, doesn't support
"is procedural" is however, never a reason to remove something. As most of PHP's function library, is procedural and works just fine. Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Kris Craig

11 years ago
On Oct 12, 2014 12:54 AM, "Derick Rethans" <derick@php.net> wrote:
> > On Sat, 11 Oct 2014, Kris Craig wrote: > > > On Oct 11, 2014 1:52 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote: > > > > > > We currently have a number of deprecated features, which we likely > > > want to remove in PHP 7. I've created a tracking RFC listing > > > deprecated functionality (if I missed something, please tell): > > > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > > > I expect many of these are no-brainers (like assigning new > > > by-reference), but other items like removal of ext/mysql may need > > > additional consideration. > > > > > > Unless there are items that are particularly contested, I'd like to > > > handle the bulk of these in a single vote and only have separate > > > votes for ext/ereg and ext/mysql, as these are arguably more > > > intrusive. > > > > +1 on all of that. > > > > As far as ext/mysql is concerned, I would eagerly vote in favor of
removing
> > it. It performs poorly, is procedural, less secure, doesn't support > > "is procedural" is however, never a reason to remove something. As most > of PHP's function library, is procedural and works just fine.
Fair point. I agree that alone wouldn't be grounds to remove it. I was just citing that as one of many deficiencies compared to more current extensions like ext/mysqli. --Kris

Derick Rethans

11 years ago
On Sat, 11 Oct 2014, Nikita Popov wrote:
> Hi internals! > > We currently have a number of deprecated features, which we likely want to > remove in PHP 7. I've created a tracking RFC listing deprecated > functionality (if I missed something, please tell): > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > I expect many of these are no-brainers (like assigning new > by-reference), but other items like removal of ext/mysql may need > additional consideration. > > Unless there are items that are particularly contested, I'd like to handle > the bulk of these in a single vote and only have separate votes for > ext/ereg and ext/mysql, as these are arguably more intrusive.
I think there should be a little bit more voting "options" - or rather categories. For example, things like this: # style comments in ini files (since PHP 5.3) I don't think we should remove at all (or why is this even deprecated?! cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Nikita Popov

11 years ago
On Sun, Oct 12, 2014 at 9:56 AM, Derick Rethans <derick@php.net> wrote:
> On Sat, 11 Oct 2014, Nikita Popov wrote: > > > Hi internals! > > > > We currently have a number of deprecated features, which we likely want > to > > remove in PHP 7. I've created a tracking RFC listing deprecated > > functionality (if I missed something, please tell): > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > I expect many of these are no-brainers (like assigning new > > by-reference), but other items like removal of ext/mysql may need > > additional consideration. > > > > Unless there are items that are particularly contested, I'd like to > handle > > the bulk of these in a single vote and only have separate votes for > > ext/ereg and ext/mysql, as these are arguably more intrusive. > > I think there should be a little bit more voting "options" - or rather > categories. > > For example, things like this: > > # style comments in ini files (since PHP 5.3) > > I don't think we should remove at all (or why is this even deprecated?! >
Because ini files use ; for comments and not #. Nikita

Maciej Sobaczewski

11 years ago
>> I think there should be a little bit more voting "options" - or rather >> categories. >> >> For example, things like this: >> >> # style comments in ini files (since PHP 5.3) >> >> I don't think we should remove at all (or why is this even deprecated?! >> > > Because ini files use ; for comments and not #. > > Nikita >
And once again it's one of the simplest things to fix. Single find&replace should do the trick in most cases. Thanks, Maciej.

Zeev Suraski

11 years ago
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Sunday, October 12, 2014 1:11 PM > To: Derick Rethans > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7 > > On Sun, Oct 12, 2014 at 9:56 AM, Derick Rethans <derick@php.net> wrote: > > > On Sat, 11 Oct 2014, Nikita Popov wrote: > > > > > Hi internals! > > > > > > We currently have a number of deprecated features, which we likely > > > want > > to > > > remove in PHP 7. I've created a tracking RFC listing deprecated > > > functionality (if I missed something, please tell): > > > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > > > I expect many of these are no-brainers (like assigning new > > > by-reference), but other items like removal of ext/mysql may need > > > additional consideration. > > > > > > Unless there are items that are particularly contested, I'd like to > > handle > > > the bulk of these in a single vote and only have separate votes for > > > ext/ereg and ext/mysql, as these are arguably more intrusive. > > > > I think there should be a little bit more voting "options" - or rather > > categories. > > > > For example, things like this: > > > > # style comments in ini files (since PHP 5.3) > > > > I don't think we should remove at all (or why is this even deprecated?! > > > > Because ini files use ; for comments and not #.
For the record, I don't feel strongly about # comments, but I do think that we should have good reasons to actually *remove* features that are better than "this is how it's done". Valid reasons can be performance penalties of keeping the feature, security issues, or potential significant reduction in codebase complexity. I'm not sure whether # comments fall into any of these buckets, but sounds like they don't. <broken_record>Each and every feature we break makes it a bit more difficult to upgrade. The more difficult we make it - the more people are likely to stick with old insecure versions, or visit alternative options</broken_record> Zeev

Andrew Faulds

11 years ago
On 12 Oct 2014, at 11:36, Zeev Suraski <zeev@zend.com> wrote:
> For the record, I don't feel strongly about # comments, but I do think that > we should have good reasons to actually *remove* features that are better > than "this is how it's done". Valid reasons can be performance penalties of > keeping the feature, security issues, or potential significant reduction in > codebase complexity. I'm not sure whether # comments fall into any of these > buckets, but sounds like they don’t.
Allowing # for comments stops you from using # in string property values. Though I’m not sure why you’d need to.
-- Andrea Faulds http://ajf.me/

Yannick Komotir

11 years ago
Hi Andrea,
> Allowing # for comments stops you from using # in string property values. > > Though I'm not sure why you'd need to.
That will be the case for any character to use for comments. Uses ; for comments will stop you from using it in values. Regards.
-- Yannick K.

Pierre Joye

11 years ago
On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski <zeev@zend.com> wrote:
> > For the record, I don't feel strongly about # comments, but I do think that > we should have good reasons to actually *remove* features that are better > than "this is how it's done". Valid reasons can be performance penalties of > keeping the feature, security issues, or potential significant reduction in > codebase complexity. I'm not sure whether # comments fall into any of these > buckets, but sounds like they don't. > > <broken_record>Each and every feature we break makes it a bit more difficult > to upgrade. The more difficult we make it - the more people are likely to > stick with old insecure versions, or visit alternative > options</broken_record>
I have to agree with Zeev here, with one additional note. We have chosen to deprecate features, including ext/mysql. If we now decide not to remove some of them for 7, we may just remove the deprecation flag as we are going to support them for the next decade as well, whether we like it or not. From the distros/pecl vs core, it is in my humble opinion, a non issue. Most of the major applications support alternative drivers now, including the most conservative ones like Wordpress (it is not badly meant, only a a statement about the situation). Distros tend to enable by default what the core provides or enables by default. PHP7 will be no different. Keeping it forever won't help. Removing it may not help as much as we wish but it will be a clear, loud and unambiguous signal, which is a good step forward. I also agree to have more options to vote on. Mass voting may hide something most of us won't notice. I also like to discuss what we do for the deprecated features we won't remove. Keeping the deprecated flags for the sake of keeping it sounds not so good. Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Julien Pauli

11 years ago
On Mon, Oct 13, 2014 at 8:51 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski <zeev@zend.com> wrote: > >> >> For the record, I don't feel strongly about # comments, but I do think that >> we should have good reasons to actually *remove* features that are better >> than "this is how it's done". Valid reasons can be performance penalties of >> keeping the feature, security issues, or potential significant reduction in >> codebase complexity. I'm not sure whether # comments fall into any of these >> buckets, but sounds like they don't. >> >> <broken_record>Each and every feature we break makes it a bit more difficult >> to upgrade. The more difficult we make it - the more people are likely to >> stick with old insecure versions, or visit alternative >> options</broken_record> > > I have to agree with Zeev here, with one additional note. > > We have chosen to deprecate features, including ext/mysql. If we now > decide not to remove some of them for 7, we may just remove the > deprecation flag as we are going to support them for the next decade > as well, whether we like it or not.
I'm +1 with that idea :-)
> > From the distros/pecl vs core, it is in my humble opinion, a non > issue. Most of the major applications support alternative drivers now, > including the most conservative ones like Wordpress (it is not badly > meant, only a a statement about the situation). Distros tend to enable > by default what the core provides or enables by default. PHP7 will be > no different. Keeping it forever won't help. Removing it may not help > as much as we wish but it will be a clear, loud and unambiguous > signal, which is a good step forward.
Yep, this would clearly show our position. After that, distros of course do what they want. Julien

Stas Malyshev

11 years ago
Hi!
>> We have chosen to deprecate features, including ext/mysql. If we now >> decide not to remove some of them for 7, we may just remove the >> deprecation flag as we are going to support them for the next decade >> as well, whether we like it or not.
I don't see how this follows. We may keep them deprecated (which means - don't use this, it's bad idea) but not remove them to support older code. Deprecated doesn't have to mean "we will mandatory remove it in the next version", it may also mean "we no longer think this is a good idea, please move on from it".
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/

Rowan Collins

11 years ago
On 12/10/2014 11:11, Nikita Popov wrote:
>> For example, things like this: >> > >> > # style comments in ini files (since PHP 5.3) >> > >> >I don't think we should remove at all (or why is this even deprecated?! >> > > Because ini files use ; for comments and not #.
I was curious enough about this to dig into source control and do some sleuthing, and it looks like what actually led to this situation was: - Between 5.2 and 5.3 (late 2007 and early 2008), the ini parsing code saw a lot of heavy modifications [1], including a patch adding many new syntax features, and a subsequent rewrite from flex to re2c. - This, inevitably, led to a bunch of regressions. As later pointed out, the accepted format wasn't really documented in the first place. [2] - One of those bugs had to do with the parsing of # characters. [3] - The behaviour of # as comments in earlier versions seems to have been a side-effect of something else, rather than a deliberate feature. In fact, it was possible to have a key starting with #, but a line starting # that had no = was silently discarded. [4] - As a result, # was added back as an explicit comment character, but with a deprecation notice. [5] My guess is that the reasoning was that semicolon was always the "correct" comment character, so people should be encouraged to use it. Whether "deprecated" is the right word for that, I'm not sure. [1] http://lxr.php.net/history/PHP_5_3/Zend/zend_ini_scanner.l [2] https://bugs.php.net/bug.php?id=47703 [3] https://bugs.php.net/bug.php?id=44575 [4] http://3v4l.org/AoI5H [5] http://lxr.php.net/diff/PHP_5_3/Zend/zend_ini_scanner.l?r2=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40b3d0514b6f87af37a7750a0f4c95e4a12a8f7009&r1=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40193dd31a22a52cfdbd30135b1025ca774d1e98b4
-- Rowan Collins [IMSoP]

Lester Caine

11 years ago
On 13/10/14 01:35, Rowan Collins wrote:
>> Because ini files use ; for comments and not #. > > - The behaviour of # as comments in earlier versions seems to have been > a side-effect of something else, rather than a deliberate feature. In > fact, it was possible to have a key starting with #, but a line starting > # that had no = was silently discarded. [4]
Are there any examples where # is used in distributed ini files? Is this something that is related to someone's particular preference in style which a particular distribution path has changed every ; to # as a quick scan across my entire server base shows no cases where it is used. Certainly some projects have changed comment coding style in the code and irritatingly dropped docblock in favour of something else but I've not see any example of # based ini comments?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Rowan Collins

11 years ago
On 13 October 2014 08:06:16 GMT+01:00, Lester Caine <lester@lsces.co.uk> wrote:
>On 13/10/14 01:35, Rowan Collins wrote: >>> Because ini files use ; for comments and not #. >> >> - The behaviour of # as comments in earlier versions seems to have >been >> a side-effect of something else, rather than a deliberate feature. In >> fact, it was possible to have a key starting with #, but a line >starting >> # that had no = was silently discarded. [4] > >Are there any examples where # is used in distributed ini files? >Is this something that is related to someone's particular preference in >style which a particular distribution path has changed every ; to # as >a >quick scan across my entire server base shows no cases where it is >used. >Certainly some projects have changed comment coding style in the code >and irritatingly dropped docblock in favour of something else but I've >not see any example of # based ini comments?
Based on the above, I think what happened is that people had used # for blocks of explanation, and ; for commented out values. While hunting down what happened, I did find some downstream bugs from one Linux distro removing # comments in reaction to the deprecation notices, so this certainly wasn't just a localised mistake.

Stas Malyshev

11 years ago
Hi! I would say we should choose according to the following criteria: 1. Is anybody likely to use it, and if so, will dropping it impede adoption significantly? 2. Would using it get you into some trouble you can't see easily? 3. How easy it's to detect that something is broken due to BC change? According to this, I think it would be really good to do this: - move mysql and ereg out to PECL (disros can bundle them anyway, and pecl is available for all self builders so adoption won't be hurt much). - drop incompatible $this context calls (probably seriously messed up code) - drop magic quotes stuff (if the code relies on magic quotes, something is seriously wrong). However, I'd consider keeping the get function (always false) to keep code that checks for it running. It wouldn't really hurt anybody I think. - drop dl on FPM - this can lead to some bad crashes - drop preg_replace() eval - it's a security problem waiting to happen - I think it can be problematic for: - # style comments in ini files, it's harder to detect and fix and as far as I can see, # doesn't hurt anybody For the rest, don't really have a strong opinion but agree with Zeev on each function being removed gets upgrade barrier a little higher and adds more people to the list of "can not upgrade, need code working". With ini settings, it's a bit easier since one ini edit fixes everything on the server, no need to check millions of lines of code. However, if we just drop them it would be hard to detect that these no longer work, maybe we should produce an error if those are used? Same for removing options from stream context - in general, if the option stopped working, I think it's better to let the user know.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/

Johannes Schlueter

11 years ago
On Mon, 2014-10-13 at 23:06 -0700, Stas Malyshev wrote:
> - drop incompatible $this context calls (probably seriously messed up > code)
Before removing: Could anybody check whether this breaks PEAR (incl. `pecl install`) I don't know how much PHP 4 legacy which required such tricks is still in there. johannes

Pierre Joye

11 years ago
On Tue, Oct 14, 2014 at 4:00 PM, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Mon, 2014-10-13 at 23:06 -0700, Stas Malyshev wrote: >> - drop incompatible $this context calls (probably seriously messed up >> code) > > Before removing: Could anybody check whether this breaks PEAR (incl. > `pecl install`) I don't know how much PHP 4 legacy which required such > tricks is still in there.
We plan to propose to bundle pickle, that should solve the pecl issue. Pickle relies strictly on 5.4+. Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Nikita Popov

11 years ago
On Sat, Oct 11, 2014 at 10:52 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > We currently have a number of deprecated features, which we likely want to > remove in PHP 7. I've created a tracking RFC listing deprecated > functionality (if I missed something, please tell): > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > I expect many of these are no-brainers (like assigning new by-reference), > but other items like removal of ext/mysql may need additional consideration. > > Unless there are items that are particularly contested, I'd like to handle > the bulk of these in a single vote and only have separate votes for > ext/ereg and ext/mysql, as these are arguably more intrusive. > > Thanks, > Nikita >
I'd like to start voting on this sometime soon. I've updated the RFC to include more info on some individual deprecated functionality and also created blocks for individual votes. I've created seven instead of the original three. If you want me to split off some point into an extra vote, please say so. I've also found that in https://wiki.php.net/rfc/incompat_ctx the vote already decided that it should be removed in the next version (-> PHP 7.0). So, anyone have a problem with dropping that right away without doing a second round of voting? Nikita RFC: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

Laruence

11 years ago
Hey: On Sun, Dec 21, 2014 at 1:33 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sat, Oct 11, 2014 at 10:52 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > >> Hi internals! >> >> We currently have a number of deprecated features, which we likely want to >> remove in PHP 7. I've created a tracking RFC listing deprecated >> functionality (if I missed something, please tell): >> >> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 >> >> I expect many of these are no-brainers (like assigning new by-reference), >> but other items like removal of ext/mysql may need additional consideration. >> >> Unless there are items that are particularly contested, I'd like to handle >> the bulk of these in a single vote and only have separate votes for >> ext/ereg and ext/mysql, as these are arguably more intrusive. >> >> Thanks, >> Nikita >> > > I'd like to start voting on this sometime soon. I've updated the RFC to > include more info on some individual deprecated functionality and also > created blocks for individual votes. I've created seven instead of the > original three. If you want me to split off some point into an extra vote, > please say so.
I am strongly against to remove ext/mysql that means, all wordpress users/maintainers, will not able to upgrade to PHP7 without pain. thanks
> > I've also found that in https://wiki.php.net/rfc/incompat_ctx the vote > already decided that it should be removed in the next version (-> PHP 7.0). > So, anyone have a problem with dropping that right away without doing a > second round of voting? > > Nikita > > RFC: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
-- Xinchen Hui @Laruence http://www.laruence.com/

Andrew Faulds

11 years ago
Hey Xinchen,
> On 21 Dec 2014, at 03:22, Xinchen Hui <laruence@php.net> wrote:
> I am strongly against to remove ext/mysql > > that means, all wordpress users/maintainers, will not able to upgrade > to PHP7 without pain.
It’d be in PECL and I’m sure every distro would package it, so there’d be no pain. But I also somewhat disagree with removing it, as if it’s in PECL having deprecation notices makes no sense, and we might get rid of them. :( Thanks.
-- Andrea Faulds http://ajf.me/

Laruence

11 years ago
Hey: On Sun, Dec 21, 2014 at 11:25 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hey Xinchen, > >> On 21 Dec 2014, at 03:22, Xinchen Hui <laruence@php.net> wrote: > >> I am strongly against to remove ext/mysql >> >> that means, all wordpress users/maintainers, will not able to upgrade >> to PHP7 without pain. > > It’d be in PECL and I’m sure every distro would package it, so there’d be no pain. > > But I also somewhat disagree with removing it, as if it’s in PECL having deprecation notices makes no sense, and we might get rid of them. :( >
actually, I hope, only hope. we release PHP7 without any big BC break, give people transparent performance improvement.. then we can do minor bc breaks in the second number releases... 7.1 , 7.2 thanks
> Thanks. > -- > Andrea Faulds > http://ajf.me/ > > > >
-- Xinchen Hui @Laruence http://www.laruence.com/

Rowan Collins

11 years ago
On 21 December 2014 03:29:54 GMT, Xinchen Hui <laruence@php.net> wrote:
>Hey: > > > >On Sun, Dec 21, 2014 at 11:25 AM, Andrea Faulds <ajf@ajf.me> wrote: >> Hey Xinchen, >> >>> On 21 Dec 2014, at 03:22, Xinchen Hui <laruence@php.net> wrote: >> >>> I am strongly against to remove ext/mysql >>> >>> that means, all wordpress users/maintainers, will not able to >upgrade >>> to PHP7 without pain. >> >> It’d be in PECL and I’m sure every distro would package it, so >there’d be no pain. >> >> But I also somewhat disagree with removing it, as if it’s in PECL >having deprecation notices makes no sense, and we might get rid of >them. :( >> >actually, I hope, only hope. > >we release PHP7 without any big BC break, give people transparent >performance improvement.. > >then we can do minor bc breaks in the second number releases... 7.1 , >7.2
That is more or less the opposite of the agreed release process - obviously we can have *minor* bc breaks later, but putting things off from a 7.0 release to encourage adoption just puts off the problem and risks 7.1 becoming a repeat of 5.3/5.4 in terms of adoption.

Ralf Lang

11 years ago
>> we release PHP7 without any big BC break, give people transparent >> performance improvement.. >> >> then we can do minor bc breaks in the second number releases... 7.1 , >> 7.2 > > That is more or less the opposite of the agreed release process - obviously we can have *minor* bc breaks later, but putting things off from a 7.0 release to encourage adoption just puts off the problem and risks 7.1 becoming a repeat of 5.3/5.4 in terms of adoption.
Right - major versions are for major changes. Minor versions are in bc hell. Actually, even the ext/mysql developer folk are not very happy with ext/mysql. Let me quote a mail from 12/2012 Adam Harvey "I ended up leaving the vote open for a couple of extra days (been a busy week), but I've now closed the ext/mysql deprecation vote. The full results are at https://wiki.php.net/rfc/mysql_deprecation — the short version is that the final vote was 25-12 in favour of deprecation in PHP 5.5. This made the second question moot, but for the record, the result there was 26-12 in favour of option (a) (deprecation in PHP 5.6 if not in PHP 5.5)." In the official Oracle mysql courses, we tell people about mysqlnd, mysqli and PDO Mysql. We tell them to get rid of ext/mysql related code - and not just since yesterday. I know this extension also runs (sort of) with mariadb. But so do others. It's time to say goodbye.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Pierre Joye

11 years ago
On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote:
> > Hey: >
> I am strongly against to remove ext/mysql > > that means, all wordpress users/maintainers, will not able to upgrade > to PHP7 without pain.
https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ Basically wp and mysql are wrong arguments. Also last time we discussed that there were a couple of oppositions to remove deprecated features in 7. My take is that we should not have a mass vote but options for each feature. Also if we do not remove deprecated features we may as a well remove the deprecation as it makes no sense to keep it if we never actually remove the affected features. Cheers, Pierre

Laruence

11 years ago
Hey: On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> > On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote: >> >> Hey: >> > >> I am strongly against to remove ext/mysql >> >> that means, all wordpress users/maintainers, will not able to upgrade >> to PHP7 without pain. > > https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ > > Basically wp and mysql are wrong arguments.
we have upgrade issues, they also have that.. I know lots of sites are based on old version wordpress, and they did lot's of custom developing on it.. they will not able to upgrade to any new wordpress..
> > Also last time we discussed that there were a couple of oppositions to > remove deprecated features in 7.
yes..
> > My take is that we should not have a mass vote but options for each feature. > Also if we do not remove deprecated features we may as a well remove the > deprecation as it makes no sense to keep it if we never actually remove the > affected features.
I agree.. for ext/mysql, I think it's okey to remove the deprecated warning.. thanks
> > Cheers, > Pierre
-- Xinchen Hui @Laruence http://www.laruence.com/

Pierre Joye

11 years ago
On Dec 21, 2014 10:50 AM, "Xinchen Hui" <laruence@php.net> wrote:
> > Hey: > > On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye <pierre.php@gmail.com>
wrote:
> > > > On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote: > >> > >> Hey: > >> > > > >> I am strongly against to remove ext/mysql > >> > >> that means, all wordpress users/maintainers, will not able to upgrade > >> to PHP7 without pain. > > > > https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ > > > > Basically wp and mysql are wrong arguments. > we have upgrade issues, they also have that.. > > I know lots of sites are based on old version wordpress, and they did > lot's of custom developing on it.. > > they will not able to upgrade to any new wordpress..
Not really our problem, is it? If they stick with 5.4.x, they should be good. But for anything with 5.5+ and wp, mysqli is used. That means that any 5.5+ and wp, they already use mysqli. However if one relies on patched core wp and did not manage to actualize their various plugins to use mysqli... Really nothing we do will help them.

Rowan Collins

11 years ago
On 21 December 2014 03:49:49 GMT, Xinchen Hui <laruence@php.net> wrote:
>Hey: > >On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye <pierre.php@gmail.com> >wrote: >> >> On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote: >>> >>> Hey: >>> >> >>> I am strongly against to remove ext/mysql >>> >>> that means, all wordpress users/maintainers, will not able to >upgrade >>> to PHP7 without pain. >> >> https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ >> >> Basically wp and mysql are wrong arguments. >we have upgrade issues, they also have that.. > >I know lots of sites are based on old version wordpress, and they did >lot's of custom developing on it.. > >they will not able to upgrade to any new wordpress..
So your concern is for people who are willing and able to upgrade to PHP 7, unable to upgrade Wordpress, and unable to install a PECL extension which will almost certainly be available as a binary package from their Linux distro? Sorry, but that seems like a rather specific group to base policy on.

Nikita

11 years ago
On Sun, 21 Dec 2014 06:49:49 +0300, Xinchen Hui <laruence@php.net> wrote:
> Hey: > > On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye <pierre.php@gmail.com> > wrote: >> >> On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote: >>> >>> Hey: >>> >> >>> I am strongly against to remove ext/mysql >>> >>> that means, all wordpress users/maintainers, will not able to upgrade >>> to PHP7 without pain. >> >> https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ >> >> Basically wp and mysql are wrong arguments. > we have upgrade issues, they also have that.. > > I know lots of sites are based on old version wordpress, and they did > lot's of custom developing on it.. > > they will not able to upgrade to any new wordpress.. > >> >> Also last time we discussed that there were a couple of oppositions to >> remove deprecated features in 7. > yes.. >> >> My take is that we should not have a mass vote but options for each >> feature. >> Also if we do not remove deprecated features we may as a well remove the >> deprecation as it makes no sense to keep it if we never actually remove >> the >> affected features. > I agree.. > > for ext/mysql, I think it's okey to remove the deprecated warning.. > > thanks >> >> Cheers, >> Pierre > > >
Hey Xinchen, Couldn't we just write a compatibility layer, like Anthony did for password_hash? (but in the opposite direction, for people who are stuck with ext/mysql and want to upgrade to 7) There'll be one problem with mysqli being an object and not a resource, but I'm sure would be able to solve it.

Pierre Joye

11 years ago
On Dec 26, 2014 5:22 PM, "Niktia Nefedov" <inefedor@gmail.com> wrote:
> > On Sun, 21 Dec 2014 06:49:49 +0300, Xinchen Hui <laruence@php.net> wrote: > >> Hey: >> >> On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye <pierre.php@gmail.com>
wrote:
>>> >>> >>> On Dec 21, 2014 10:23 AM, "Xinchen Hui" <laruence@php.net> wrote: >>>> >>>> >>>> Hey: >>>> >>> >>>> I am strongly against to remove ext/mysql >>>> >>>> that means, all wordpress users/maintainers, will not able to upgrade >>>> to PHP7 without pain. >>> >>> >>> https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ >>> >>> Basically wp and mysql are wrong arguments. >> >> we have upgrade issues, they also have that.. >> >> I know lots of sites are based on old version wordpress, and they did >> lot's of custom developing on it.. >> >> they will not able to upgrade to any new wordpress.. >> >>> >>> Also last time we discussed that there were a couple of oppositions to >>> remove deprecated features in 7. >> >> yes.. >>> >>> >>> My take is that we should not have a mass vote but options for each
feature.
>>> Also if we do not remove deprecated features we may as a well remove the >>> deprecation as it makes no sense to keep it if we never actually remove
the
>>> affected features. >> >> I agree.. >> >> for ext/mysql, I think it's okey to remove the deprecated warning.. >> >> thanks >>> >>> >>> Cheers, >>> Pierre >> >> >> >> > > Hey Xinchen, > > Couldn't we just write a compatibility layer, like Anthony did for
password_hash? (but in the opposite direction, for people who are stuck with ext/mysql and want to upgrade to 7)
> > There'll be one problem with mysqli being an object and not a resource,
but I'm sure would be able to solve it. There is already one, written by Ulf back then.

Nikita Popov

11 years ago
On Sun, Dec 21, 2014 at 4:22 AM, Xinchen Hui <laruence@php.net> wrote:
> Hey: > > On Sun, Dec 21, 2014 at 1:33 AM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > On Sat, Oct 11, 2014 at 10:52 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > > >> Hi internals! > >> > >> We currently have a number of deprecated features, which we likely want > to > >> remove in PHP 7. I've created a tracking RFC listing deprecated > >> functionality (if I missed something, please tell): > >> > >> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > >> > >> I expect many of these are no-brainers (like assigning new > by-reference), > >> but other items like removal of ext/mysql may need additional > consideration. > >> > >> Unless there are items that are particularly contested, I'd like to > handle > >> the bulk of these in a single vote and only have separate votes for > >> ext/ereg and ext/mysql, as these are arguably more intrusive. > >> > >> Thanks, > >> Nikita > >> > > > > I'd like to start voting on this sometime soon. I've updated the RFC to > > include more info on some individual deprecated functionality and also > > created blocks for individual votes. I've created seven instead of the > > original three. If you want me to split off some point into an extra > vote, > > please say so. > > I am strongly against to remove ext/mysql > > that means, all wordpress users/maintainers, will not able to upgrade > to PHP7 without pain. >
Please take a look at the WordPress version statistics: https://wordpress.org/about/stats/ According to these statistics 72% of the WordPress installations are running on either PHP 5.2 or PHP 5.3. This means that they do not benefit from the quite substantial performance and memory usage improvements that went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 to PHP 5.4, I don't see how they'd be more interested in PHP 7. And, as already mentioned, WP already supports mysqli since version 3.9, so people who want to use PHP 7 can do so with a reasonably current version of WP. But anyway, I get that not everyone agrees with removing ext/mysql - that's why we're having votes on this kind of stuff ;) Nikita

Alain Williams

11 years ago
On Sun, Dec 21, 2014 at 02:30:28PM +0100, Nikita Popov wrote:
> Please take a look at the WordPress version statistics: > https://wordpress.org/about/stats/ > > According to these statistics 72% of the WordPress installations are > running on either PHP 5.2 or PHP 5.3. This means that they do not benefit > from the quite substantial performance and memory usage improvements that > went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 > to PHP 5.4, I don't see how they'd be more interested in PHP 7.
I am running PHP 5.3.3 on my servers. Why ? Summary: running newer versions is a lot of effort. I run CentOS 6 so I run the PHP that is packaged for it. While it might be nice to have PHP 5.6 it would involve me in a lot of work (compile from source) and I would need to do that with each new release/patch. As it is I just go 'yum update' and security fixes, ..., are all installed - easy peasy. If I were to upgrade to CentOS 7 (a lot of work - but it is what I put on new ones) I would have PHP 5.4. The RedHat support term is 10 years and will still be in common use until 2020. I like that - putting a server together can be a lot of work; it can do a lot more than just run PHP. If PHP 5.<latest> were available in EPEL[**] I would look to upgrade to a more modern PHP. EPEL would make use much easier. It will not happen without someone putting the work in ... and it is much more than just compiling the tar ball, there must be patching and testing in the enterprise environment. [**] A place where other RedHat packages live, sometimes more modern versions of packages in the base distribution. http://fedoraproject.org/wiki/EPEL
> And, as already mentioned, WP already supports mysqli since version 3.9, so > people who want to use PHP 7 can do so with a reasonably current version of > WP. > > But anyway, I get that not everyone agrees with removing ext/mysql - that's > why we're having votes on this kind of stuff ;) > > Nikita
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Alexey Zakhlestin

11 years ago
> On 21 Dec 2014, at 16:53, Alain Williams <addw@phcomp.co.uk> wrote: > > On Sun, Dec 21, 2014 at 02:30:28PM +0100, Nikita Popov wrote: > > >> Please take a look at the WordPress version statistics: >> https://wordpress.org/about/stats/ >> >> According to these statistics 72% of the WordPress installations are >> running on either PHP 5.2 or PHP 5.3. This means that they do not benefit >> from the quite substantial performance and memory usage improvements that >> went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 >> to PHP 5.4, I don't see how they'd be more interested in PHP 7. > > I am running PHP 5.3.3 on my servers. Why ? > > Summary: running newer versions is a lot of effort. > > I run CentOS 6 so I run the PHP that is packaged for it. While it might be nice > to have PHP 5.6 it would involve me in a lot of work (compile from source) and I > would need to do that with each new release/patch. As it is I just go 'yum > update' and security fixes, ..., are all installed - easy peasy.
did you hear about RHSCL? http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/ it solves this usecase nicely
-- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

Alain Williams

11 years ago
On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote:
> did you hear about RHSCL? > http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/
Yes. That gives me PHP 5.4: http://wiki.centos.org/AdditionalResources/Repositories/SCL?highlight=%28software%29|%28collections%29 SCL 1.1 is supposed to give me PHP 5.5, but I cannot see it.
> it solves this usecase nicely
I don't think so --- please show me that I am wrong. Debian testing is better it is on PHP 5.6.2 Debian stable is on PHP 5.4.35 But my point remains: many people stick with what comes with the operating system distribution. Showing them easy ways of upgrading and staying (security) patched might help.
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>

Ralf Lang

11 years ago
On 21.12.2014 16:12, Alain Williams wrote:
> On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote: > >> did you hear about RHSCL? >> http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/ > > But my point remains: many people stick with what comes with the operating > system distribution.
And they will switch when the OS Vendor switches. This is completely separate from what these versions do contain. BTW, if you need latest PHP rpm's for distribution $foo, you will probably find them on open build service.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Pierre Joye

11 years ago
On Dec 22, 2014 12:27 PM, "Ralf Lang" <lang@b1-systems.de> wrote:
> > On 21.12.2014 16:12, Alain Williams wrote: > > On Sun, Dec 21, 2014 at 05:23:53PM +0300, Alexey Zakhlestin wrote: > > > >> did you hear about RHSCL? > >>
http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/
> > > > But my point remains: many people stick with what comes with the
operating
> > system distribution. > > And they will switch when the OS Vendor switches. This is completely > separate from what these versions do contain. > > BTW, if you need latest PHP rpm's for distribution $foo, you will > probably find them on open build service.
Or Remi's repo. Best thing ever :)

Alain Williams

11 years ago
On Mon, Dec 22, 2014 at 05:04:23PM +1100, Pierre Joye wrote:
> Or Remi's repo. Best thing ever :)
Oh - that is news for me! http://remi.check-update.co.uk/ Could I suggest that things like this are linked to from here: http://uk1.php.net/downloads.php Even if you feel that there must be a disclaimer like 'not officially endorsed by the PHP group'. That would be really useful!
-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h>