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
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_php7I 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
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
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
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.
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
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
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.
Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
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 in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
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.
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)
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_php7I 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
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_php7I 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
--
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
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_php7I 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
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_php7I 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
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.
-----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 7Hi 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_php7I 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
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/
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.
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
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
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/
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]
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 startingthat 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
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
startingthat 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.
Hi!
I would say we should choose according to the following criteria:
- Is anybody likely to use it, and if so, will dropping it impede
adoption significantly? - Would using it get you into some trouble you can't see easily?
- 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/
- 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
On Tue, Oct 14, 2014 at 4:00 PM, Johannes Schlüter
johannes@schlueters.de 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
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_php7I 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
Hey:
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_php7I 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,
NikitaI'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/
Hey Xinchen,
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/
Hey:
Hey Xinchen,
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/
Hey:
Hey Xinchen,
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.
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.2That 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
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
Hey:
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/
Hey:
On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre.php@gmail.com
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.
Hey:
On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre.php@gmail.com
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.
Hey:
On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre.php@gmail.com
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.
Hey:
On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre.php@gmail.com
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,
PierreHey 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.
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_php7I 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,
NikitaI'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
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
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
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
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
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 :)
--
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
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
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!
offtopic:
we used to do that, but is was problematic, there were high demand getting
to that list (AFAIR there were even cases when somebody tried to get a
concurrent product/project from that page) and we don't really have the
time to keep the list up-to-date and do quality control over such third
parties, so the consensus was to remove them:
http://git.php.net/?p=web/php.git;a=commit;h=6dfbaafab81e5b53419f95a5203a2b4e30e46a98
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu