# [RFC] Deprecations for PHP 7.2 - Thread: https://externals.io/message/96993 - Original archive: https://news-web.php.net/php.internals/96993 - Started by Nikita Popov on 2016-11-18T14:55:23+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/96993.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #96993 — Nikita Popov — 2016-11-18T14:55:23+00:00 URL: https://externals.io/message/96993#96993 Hi internals! I've submitted this RFC for PHP 7.1 previously, but didn't follow through due to time constraints. Now I'd like to propose an extended version for PHP 7.2 and vote on it sooner rather than later to avoid a repeat performance. https://wiki.php.net/rfc/deprecations_php_7_2 The RFC combines a number of deprecation and removal proposals. Each one will get a separate 2/3 majority vote. The RFC overlaps with some recently discussed topics (each, binary strings) -- I'm fine with dropping these if someone has a more specific RFC. I expect some of these are no-brainers, while others are more controversial -- please share your specific concerns. Thanks, Nikita --- ## #96998 — Christoph M. Becker — 2016-11-18T17:45:58+00:00 URL: https://externals.io/message/96993#96998 · In reply to: #96993 > Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. > > I expect some of these are no-brainers, while others are more controversial > -- please share your specific concerns. Thanks, Nikita! I'm generally in favor of such clean up. The only exception would be features which have only been available as of PHP 7, currently only assertion expressions. Deprecating assertion strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2 compatible code, even though 7.2 GA is supposed to be released in December 2017, whereas there'll be security support for 5.6 until end of 2018[1]. [1] -- Christoph M. Becker --- ## #97005 — Kalle Sommer Nielsen — 2016-11-18T19:01:28+00:00 URL: https://externals.io/message/96993#97005 · In reply to: #96993 Hi Nikita 2016-11-18 15:55 GMT+01:00 Nikita Popov : > Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. > > I expect some of these are no-brainers, while others are more controversial > -- please share your specific concerns. Awesome list, thanks for your work. I got a couple of things to maybe consider adding: arg_separator.output/input -- Do we really need an ini to define these, can't they be baked in or something? (I did not look at the code) auto_prepend/auto_append_file directives, I would be amazed if there couldn't be some optimization complications with those too register_argv_argc -- deprecate for non CLI? Might have other things to add later on, these are just what I had in mind so far -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97007 — Jan Ehrhardt — 2016-11-18T21:04:33+00:00 URL: https://externals.io/message/96993#97007 · In reply to: #96993 Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100): > https://wiki.php.net/rfc/deprecations_php_7_2 > >The RFC combines a number of deprecation and removal proposals. Each one >will get a separate 2/3 majority vote. The RFC overlaps with some recently >discussed topics (each, binary strings) I must have missed the discussion about each(). And this really surprised me: > The each() function is inferior to foreach in pretty much every > imaginable way, including being more than 10 times slower. But it is mentioned in a 9-year old comment in the manual: https://php.net/manual/en/function.each.php#75692 A quick grep in my Drupal7 source code showed that not everybody is aware of that. For instance, even the views module use a list() = each() construction: http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740 This means that at least 800,000 sites use list() = each() at the moment. I am fine with deprecation, but this may be more wide spread than one might assume. -- Jan --- ## #97008 — Christoph M. Becker — 2016-11-18T23:42:03+00:00 URL: https://externals.io/message/96993#97008 · In reply to: #97005 > 2016-11-18 15:55 GMT+01:00 Nikita Popov : > > > […] > > Awesome list, thanks for your work. I got a couple of things to maybe > consider adding: > > arg_separator.output/input -- Do we really need an ini to define > these, can't they be baked in or something? (I did not look at the > code) See also a recent discussion on comp.lang.php: . TL;DR: these ini settings may cause quite some confusion (note that the OP is a long-term PHP developer), but removing them might cause considerable BC breakage. We have to be very careful here, IMHO. -- Christoph M. Becker --- ## #97010 — Yasuo Ohgaki — 2016-11-19T00:05:58+00:00 URL: https://externals.io/message/96993#97010 · In reply to: #97005 Hi all, > auto_prepend/auto_append_file directives auto_prepend/append_file is handy to check application performance/statistical information such as memory usage while development and/or testing, for example. Do these harm any other than shooting their own foot? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #97011 — Kalle Sommer Nielsen — 2016-11-19T00:25:03+00:00 URL: https://externals.io/message/96993#97011 · In reply to: #97010 2016-11-19 1:05 GMT+01:00 Yasuo Ohgaki : > Hi all, > > > > […] > > auto_prepend/append_file is handy to check application > performance/statistical information such as memory usage while > development and/or testing, for example. Do these harm any other than > shooting their own foot? > Maybe not so much, but I'd like to hear any impact they could have on optimization much like some of the features in the RFC is mentioned to be problematic. I did used to use those directives for similar things, but it was a decade ago :/ -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97024 — Tony Marston — 2016-11-19T10:18:17+00:00 URL: https://externals.io/message/96993#97024 · In reply to: #96993 "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com... > >Hi internals! > >I've submitted this RFC for PHP 7.1 previously, but didn't follow through >due to time constraints. Now I'd like to propose an extended version for >PHP 7.2 and vote on it sooner rather than later to avoid a repeat >performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > >The RFC combines a number of deprecation and removal proposals. Each one >will get a separate 2/3 majority vote. The RFC overlaps with some recently >discussed topics (each, binary strings) -- I'm fine with dropping these if >someone has a more specific RFC. > >I expect some of these are no-brainers, while others are more controversial >-- please share your specific concerns. > >Thanks, >Nikita I am against the removal of the $errorcontext argument of error handler as this has been a valuable part of my error handler for over ten years. Whenever `trigger_error()` is called with a fatal error I write all available details to a log file as well as sending an email. In order to obtain additional data I use errorcontext to determine the following: a) Was it called from a function or an object? For this I use code such as the following: if (isset($errcontext['this']) AND is_object($errcontext['this'])) { b) If it was called from an object, was it one of my database objects? If yes, then obtain some extra information using code such as the following: // retrieve error details from DML object if (method_exists($errcontext['this'], 'getQuery')) { $query = $errcontext['this']->getQuery(); } // if if (method_exists($errcontext['this'], 'getErrorNo')) { $errno = $errcontext['this']->getErrorNo(); } // if if (method_exists($errcontext['this'], 'getErrorString')) { $errstr = $errcontext['this']->getErrorString(); } // if if (method_exists($errcontext['this'], 'getErrorString2')) { $errstr2 = $errcontext['this']->getErrorString2(); } // if Saying that I should stop using $errorcontext and instead use a debugger is very short sighted. I *NEED* to have this data available in the error log as soon as the error happens. In several cases I cannot use a debugger as my application is running behind a client's firewall and their security restrictions forbid the use of a debugger from outside of that firewall. I notice that the reason for this recommendation is "because the $errcontext can be used to modify all references and objects in the current scope." If this is the case then why not make $errorcontext read-only so that nothing can be changed. I can imagine lots of people reading from $errorcontext, but how many actually write? I certainly don't. -- Tony Marston --- ## #97028 — Nikita Popov — 2016-11-19T11:20:55+00:00 URL: https://externals.io/message/96993#97028 · In reply to: #97024 On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston wrote: > "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er= > G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com... > > > > […] > > I am against the removal of the $errorcontext argument of error handler as > this has been a valuable part of my error handler for over ten years. > Whenever `trigger_error()` is called with a fatal error I write all available > details to a log file as well as sending an email. In order to obtain > additional data I use errorcontext to determine the following: > > a) Was it called from a function or an object? For this I use code such as > the following: > > if (isset($errcontext['this']) AND is_object($errcontext['this'])) { > > b) If it was called from an object, was it one of my database objects? If > yes, then obtain some extra information using code such as the following: > > // retrieve error details from DML object > if (method_exists($errcontext['this'], 'getQuery')) { > $query = $errcontext['this']->getQuery(); > } // if > if (method_exists($errcontext['this'], 'getErrorNo')) { > $errno = $errcontext['this']->getErrorNo(); > } // if > if (method_exists($errcontext['this'], 'getErrorString')) { > $errstr = $errcontext['this']->getErrorString(); > } // if > if (method_exists($errcontext['this'], 'getErrorString2')) { > $errstr2 = $errcontext['this']->getErrorString2(); > } // if > I'm afraid you're out of luck here :/ This usage will no longer be possible as of PHP 7.1 -- independently of the deprecation proposed in this RFC. See: https://3v4l.org/sQBL9 Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be more precise, whenever $this was used as a CV, rather than implicit UNUSED operand). As of PHP 7.1 $this is never included in the symbol table. This change is due to https://wiki.php.net/rfc/this_var. But! This functionality is still available through `debug_backtrace()`. That's the correct way of fetching the $this of a parent frame, which should always work (rather than *sometimes* on PHP < 7.1), and is independent of the error handling mechanism. So, to clarify: Is $this the only thing from the error context you're interested in? Or do you also use all the other variables? > Saying that I should stop using $errorcontext and instead use a debugger > is very short sighted. I *NEED* to have this data available in the error > log as soon as the error happens. In several cases I cannot use a debugger > as my application is running behind a client's firewall and their security > restrictions forbid the use of a debugger from outside of that firewall. > I notice that the reason for this recommendation is "because the > $errcontext can be used to modify all references and objects in the current > scope." If this is the case then why not make $errorcontext read-only so > that nothing can be changed. I can imagine lots of people reading from > $errorcontext, but how many actually write? I certainly don't. We can do this for references (i.e., dereference them for the provided symbol table), but not for objects, because we don't have any way of enforcing immutability on the language side. Thanks, Nikita --- ## #97029 — Nikita Popov — 2016-11-19T11:32:03+00:00 URL: https://externals.io/message/96993#97029 · In reply to: #96998 On Fri, Nov 18, 2016 at 6:45 PM, Christoph M. Becker wrote: > > > […] > recently > > […] > if > > […] > controversial > > […] > > Thanks, Nikita! I'm generally in favor of such clean up. > > The only exception would be features which have only been available as > of PHP 7, currently only assertion expressions. Deprecating assertion > strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2 > compatible code, even though 7.2 GA is supposed to be released in > December 2017, whereas there'll be security support for 5.6 until end of > 2018[1]. > > [1] > This is a reasonable concern. My opinion on `assert()` and PHP 5 vs PHP 7 is basically this: You can use `assert()` the same way in PHP 5 as you do in PHP 7. Assertion expressions *are* supported in PHP 5. The only difference is that it's not zero-cost and error reporting is slightly worse. And well, PHP 5 being slower than PHP 7 is kinda the case whether you use assertions or not. If you use PHP 5, performance is clearly your primary concern. Thanks, Nikita --- ## #97057 — Rowan Collins — 2016-11-19T17:23:19+00:00 URL: https://externals.io/message/96993#97057 · In reply to: #96993 > Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > Hi Nikita, I'm interested to see create_function() on this list, as one of my first contributions to the list was suggesting its deprecation, and I didn't feel there was sufficient consensus to go forward. Thread here: http://marc.info/?t=138178649200002&r=2&w=2 http://marc.info/?t=138178649200002&r=1&w=2 It's possible the intervening three years have changed things sufficiently to reconsider, though. On a broader note, I would like to restate my desire for some kind of road map or plan of roughly when 8.0 is expected, to inform decisions on things like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or 10? Previously I've been answered with "the Big Feature of 8.0 will be JIT", but I am not a fan of tying the deprecation and feature policy to "whenever we happen to have a rewrite of the engine ready"; it muddles product branding with API versioning. If JIT isn't ready for 10 years, does that mean we have to wait 10 years to break BC? And if it's ready in 2018, does that mean everything deprecated in 7.2 has to be immediately dropped after just one year? Should we decouple the Zend Engine version from the language version, and use separate semantic versions for each? Regards, -- Rowan Collins [IMSoP] --- ## #97060 — Kalle Sommer Nielsen — 2016-11-19T17:42:10+00:00 URL: https://externals.io/message/96993#97060 · In reply to: #97057 Hi Rowan 2016-11-19 18:23 GMT+01:00 Rowan Collins : > On a broader note, I would like to restate my desire for some kind of road > map or plan of roughly when 8.0 is expected, to inform decisions on things > like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or > 10? > > Previously I've been answered with "the Big Feature of 8.0 will be JIT", but > I am not a fan of tying the deprecation and feature policy to "whenever we > happen to have a rewrite of the engine ready"; it muddles product branding > with API versioning. If JIT isn't ready for 10 years, does that mean we have > to wait 10 years to break BC? And if it's ready in 2018, does that mean > everything deprecated in 7.2 has to be immediately dropped after just one > year? Should we decouple the Zend Engine version from the language version, > and use separate semantic versions for each? I kinda liked the model we had back in the late 5.x series (namely starting with 5.3 from 2009), although that was before we had a release plan decided, it did make a lot of sense to deprecate some features, of course taking into consideration what they are and the impact they have. The model we had was deprecate in x.z, then remove in z+1, things to this list include safe_mode, register_globals for example, not that these were as ground breaking changes because of the movement to use PHP5. I think create_function(), as mentioned, is a feature worthy of being deprecated in one version, then removed in the next. Like you also mention, major versions are really rare and I think it should be kept that way, or at least until we reach a point where we literally cannot improve PHP7 anymore without major changes, such as the case for PHP 5.6 was. Side note, I still think that with the amount of work, changes and features, PHP 5.3 was almost worth the role of being a major version, but lets not side track the subject ;-) With our current model, that means that when we deprecate something, users got a year to upgrade their code, if they are bleeding edge users, but most are likely not, so they have more time to upgrade the code, and to be fair, we try to do the removals in moderate parts to not overwhelm developers who are upgrading their code, or projects that supports a wide range of PHP versions, such as phpB which support PHP 5.3.0+. After that 1 year, we do offer 2 years additional security fixes support, so I think that there is more than enough time for our community to update their code bases. PHP 7.0 was a great success externally for migration. So to answer your question in a short without much more rambling: I think we should deprecate in x.z, then remove in x.z+1 depending on the feature, if we say "Oh let's remove this in the next major", chances are that major won't even be branches for years, and at that time, it could be forgotten. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97062 — Marco Pivetta — 2016-11-19T17:56:01+00:00 URL: https://externals.io/message/96993#97062 · In reply to: #97060 > So to answer your question in a short without much more rambling: I > think we should deprecate in x.z, then remove in x.z+1 depending on > the feature, if we say "Oh let's remove this in the next major", > chances are that major won't even be branches for years, and at that > time, it could be forgotten. > That will end up breaking the "expected" (because it's not that way anyway, but almost) SemVer approach, diminishing the trust from consumers in any kind of upgrade. Most of the current open-source libs out there are trying to push for SemVer - having PHP not following that seems like a huge mess to me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #97064 — Christoph M. Becker — 2016-11-19T18:16:15+00:00 URL: https://externals.io/message/96993#97064 · In reply to: #97062 > > > > […] > > That will end up breaking the "expected" (because it's not that way anyway, > but almost) SemVer approach, diminishing the trust from consumers in any > kind of upgrade. > Most of the current open-source libs out there are trying to push for > SemVer - having PHP not following that seems like a huge mess to me. Our release process[1] explicitly forbids breaking userland API between x.y.z and x.y+1.z. [1] -- Christoph M. Becker --- ## #97065 — Christoph M. Becker — 2016-11-19T18:23:01+00:00 URL: https://externals.io/message/96993#97065 · In reply to: #97057 > On a broader note, I would like to restate my desire for some kind of > road map or plan of roughly when 8.0 is expected, to inform decisions on > things like this. Does "deprecate in 7.2" mean removal in 2 years time, > or 5, or 10? > > Previously I've been answered with "the Big Feature of 8.0 will be JIT", > but I am not a fan of tying the deprecation and feature policy to > "whenever we happen to have a rewrite of the engine ready"; it muddles > product branding with API versioning. If JIT isn't ready for 10 years, > does that mean we have to wait 10 years to break BC? And if it's ready > in 2018, does that mean everything deprecated in 7.2 has to be > immediately dropped after just one year? Should we decouple the Zend > Engine version from the language version, and use separate semantic > versions for each? IMHO, we should consider introducing a fixed schedule for major releases (say, every 4 years). -- Christoph M. Becker --- ## #97067 — Kalle Sommer Nielsen — 2016-11-19T18:29:31+00:00 URL: https://externals.io/message/96993#97067 · In reply to: #97062 Hi Marco 2016-11-19 18:56 GMT+01:00 Marco Pivetta : > That will end up breaking the "expected" (because it's not that way anyway, > but almost) SemVer approach, diminishing the trust from consumers in any > kind of upgrade. > Most of the current open-source libs out there are trying to push for SemVer > - having PHP not following that seems like a huge mess to me. I don't think a SemVer approach will work for PHP in its current state, not to say that it won't but the way that some of these things are implemented, it makes complications for further internal improvements that comes with each major/minor release. Take the "Forbid Dynamic Scope Introspection" RFC you voted yes to, which is implemented in PHP 7.1, sure, this one in particular is on the path down to pandora's PHP edge case box, but without it we would have lost speed gain optimizations (faster PHP by upgrading) and have to stick around with code that could lead to pitfalls, hard to debug code or nasty crashes. I do understand that we have to draw a line in what is sensible to deprecate and remove in favor of what and when, but keep in mind how large a userbase PHP serves, hundreds of millions of websites, millions of developers and yet we are maybe about 20 active developers who contribute code to PHP's internals on a regular basis. Time, resources and energy for keeping things in closed state for so long where we cannot change anything is not fun or motivating for contributing. (And I would rather not that PHP felt into a version scheme similar to that of Chrome where in December we could have PHP 42.0.) [1] https://wiki.php.net/rfc/forbid_dynamic_scope_introspection -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97068 — Rowan Collins — 2016-11-19T18:34:21+00:00 URL: https://externals.io/message/96993#97068 · In reply to: #97062 > On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen > wrote: > > So to answer your question in a short without much more rambling: I > think we should deprecate in x.z, then remove in x.z+1 depending on > the feature, if we say "Oh let's remove this in the next major", > chances are that major won't even be branches for years, and at that > time, it could be forgotten. > > > That will end up breaking the "expected" (because it's not that way > anyway, but almost) SemVer approach, diminishing the trust from > consumers in any kind of upgrade. > Most of the current open-source libs out there are trying to push for > SemVer - having PHP not following that seems like a huge mess to me. > I agree with this, to an extent. If we formally disavow any meaning of "major release" other than branding, the expectation is less of an issue in itself. But it's interesting that PostgreSQL is moving to a 2-part version numbering: instead of the annual feature releases being 9.7.0, 9.8.0, 9.9.0 etc, they will be 10.0, 11.0, 12.0, thus eliminating debate about which releases should be classed as "major". > Like you also mention, major versions are really rare and I > think it should be kept that way, or at least until we reach a point > where we literally cannot improve PHP7 anymore without major changes, > such as the case for PHP 5.6 was. What is a "major change", if you want to abandon the link to compatibility? Do you mean "headline-grabbing feature", i.e. versioning as a brand? > With our current model, that means that when we deprecate something, > users got a year to upgrade their code, if they are bleeding edge > users, but most are likely not, so they have more time to upgrade the > code This is a recipe for massive version fragmentation. When x.3 comes out, some people will be stuck on x.0, some on x.1, some on x.2, etc; library authors won't be able to take advantage of the features introduced in x.3, and everyone has to remember just what's new in each release. I actually think major releases should be *more* common, to reduce the temptation to "bend" the rules, and break compatibility early. The policy could be as simple as "every major release will have between 3 and 5 minor releases". Then the earliest release of 8.0 would be after 7.2 (late 2018 / early 2019), and the latest would be after 7.4 (late 2020 / early 2021). Having a road map in advance also means you can branch early, break things, and know how long you're going to have to maintain that branch for. Regards, -- Rowan Collins [IMSoP] --- ## #97069 — Kalle Sommer Nielsen — 2016-11-19T18:35:49+00:00 URL: https://externals.io/message/96993#97069 · In reply to: #97065 Hi Christoph 2016-11-19 19:23 GMT+01:00 Christoph M. Becker : > IMHO, we should consider introducing a fixed schedule for major releases > (say, every 4 years). I think that should depend on a case by case basis for when we are working towards a new version, a lot of awesome work are already in for master that won't be out for at least another year. At the point when we pick RMs for the next branch, then we have in the past evaluated the scope of changes currently planned to be included, what is currently in and what the magical guys at Zend are doing and decide there. Having a fixed, forced major version does not sound that great if we do not have something awesome that could only ever exist in a new major version, -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97073 — Christoph M. Becker — 2016-11-19T18:56:15+00:00 URL: https://externals.io/message/96993#97073 · In reply to: #97069 Hi Kalle! > 2016-11-19 19:23 GMT+01:00 Christoph M. Becker : > > > […] > > I think that should depend on a case by case basis for when we are > working towards a new version, a lot of awesome work are already in > for master that won't be out for at least another year. At the point > when we pick RMs for the next branch, then we have in the past > evaluated the scope of changes currently planned to be included, what > is currently in and what the magical guys at Zend are doing and decide > there. Having a fixed, forced major version does not sound that great > if we do not have something awesome that could only ever exist in a > new major version, But this short-dated decision on whether next will be a major or minor is exactly the problem. Consider, for instance, this RFC which targets 7.2 for deprecation and 8.0 for removal. What if we decide in some month that there'll be no 7.2, but rather 8.0 will be next? Would we remove the features without a deprecation phase, or would we deprecate them for 8.0 and remove later? Either way, I'm pretty sure that we would have a lenghty discussion, and might even need another vote. And at least some RFCs and documentation would have to be fixed. At the very least I would suggest to decide whether the next version but one will be major or minor at the same time we tag the first alpha of the next version. I.e. this decision would had been made months ago, and actually all RFCs I've read assume that PHP 7.2 will be next. -- Christoph M. Becker --- ## #97074 — Kalle Sommer Nielsen — 2016-11-19T19:10:09+00:00 URL: https://externals.io/message/96993#97074 · In reply to: #97073 Hi Christoph 2016-11-19 19:56 GMT+01:00 Christoph M. Becker : > Hi Kalle! > > But this short-dated decision on whether next will be a major or minor > is exactly the problem. Consider, for instance, this RFC which targets > 7.2 for deprecation and 8.0 for removal. What if we decide in some > month that there'll be no 7.2, but rather 8.0 will be next? Would we > remove the features without a deprecation phase, or would we deprecate > them for 8.0 and remove later? Either way, I'm pretty sure that we > would have a lenghty discussion, and might even need another vote. And > at least some RFCs and documentation would have to be fixed. That is a valid concern I agree. I just have a hard time wrapping my head around what if we don't have anything ground breaking for a major that I would expect in any major, what differences does it then make for it to not be a minor. I'm a little skeptical on having a pre determined plan, I do see pros/cons for both sides of the argument and I reckon the point you raised to be of a possible con of not having a pre determined plan. But I do kinda like Rowan's idea of a major within x or y releases from last major. Gonna think about this for a bit... -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97078 — Rowan Collins — 2016-11-19T21:56:24+00:00 URL: https://externals.io/message/96993#97078 · In reply to: #97069 > Having a fixed, forced major version does not sound that great if we > do not have something awesome that could only ever exist in a new > major version Again, you're looking at version numbers as primarily a branding thing ("something awesome") rather than a technical thing ("something that breaks compatibility"). I think this is the biggest thing that the formal SemVer standard forces a developer to accept: you don't get to choose when something "deserves" a major version number, you MUST increment it when you break compatibility. As the FAQ on semver.org says, if you reach 42.0.0 very rapidly under SemVer, that's because your API isn't stable; pretending some of those versions are minor releases is just masking the problem. If we adopted SemVer (which I'm not particularly proposing, just offering as comparison) there is absolutely zero chance that 4 years would pass without us having a single change which warranted a major version bump. As soon as you have one feature marked deprecated, then the release where that is removed is a major release, regardless of what else it has. That's why I mentioned divorcing the Engine and Language versions: if we don't want to brand something as "PHP 8" unless it's got shinies, then you could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm not sure that split does quite work, but it would at least make explicit the difference between brand version and compatibility version. Regards, -- Rowan Collins [IMSoP] --- ## #97080 — Kalle Sommer Nielsen — 2016-11-19T23:05:10+00:00 URL: https://externals.io/message/96993#97080 · In reply to: #97078 2016-11-19 22:56 GMT+01:00 Rowan Collins : > Again, you're looking at version numbers as primarily a branding thing > ("something awesome") rather than a technical thing ("something that breaks > compatibility"). Yes because that has been our past model for a long time. Like I mentioned, PHP 5.3 should probably have been a major considering the changes it did. It wasn't until PHP 5.3 that we introduced E_DEPREPCATED and actively started taking out problematic features which in the past had caused issues with the usual group of people who don't care to read the manual, so we gave those features a little longer life span while informing the developers that we are gonna remove it. Basically before we started to get all political of things, which is both good and bad, then a new x+1.z or x.z+1 version was based off having a large number of features that branded that version as a whole, and I think that is perfectly fine. > I think this is the biggest thing that the formal SemVer standard forces a > developer to accept: you don't get to choose when something "deserves" a > major version number, you MUST increment it when you break compatibility. As > the FAQ on semver.org says, if you reach 42.0.0 very rapidly under SemVer, > that's because your API isn't stable; pretending some of those versions are > minor releases is just masking the problem. If we were to rename past releases to a scheme by SemVer, then that would pretty much have been a yearly major, that is extremely poor versioning in my opinion when we retrain such a high backwards compatibility rate otherwise. I don't like the thought that PHP 5.4 could have been PHP 6 just because we removed safe_mode, that was deprecated in 5.3. That would be a disappointing reason just to go for a new major. I think the main reason we reserve major versions, and have in the past is that the internal API is very compatible across minor versions, 5.x even contained macros for PHP4 extensions to be mostly compatible or even loadable pre 4.3 extensions for a long time if I remember correctly (I think it was Julien that removed that in 5.5). > If we adopted SemVer (which I'm not particularly proposing, just offering as > comparison) there is absolutely zero chance that 4 years would pass without > us having a single change which warranted a major version bump. As soon as > you have one feature marked deprecated, then the release where that is > removed is a major release, regardless of what else it has. Same as above, I dislike this rapid jumping in versioning. Though this is my personal opinion, for me as a Core Developer of PHP, I prefer this scheme as it makes sense to me as it is pretty much what it always has been. Taking Chrome, or well Blink as I use Opera, as an example, I don't see the big point in that every few weeks I get a new major version of my browser because some handy new feature was added, might as well have been a minor release, like Opera used to be in the Presto days. > > That's why I mentioned divorcing the Engine and Language versions: if we > don't want to brand something as "PHP 8" unless it's got shinies, then you > could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm not sure > that split does quite work, but it would at least make explicit the > difference between brand version and compatibility version. I don't think that will work as most people when you say the Zend Engine that is not into the PHP.net project will maybe know that its the core of PHP, but nothing more about it so I don't think it makes much sense to suddenly start label releases as such. PHP for almost two decades have only been released with Zend Engine and they are so coupled together today that I doubt you can build LibZend standalone anymore. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #97094 — Rowan Collins — 2016-11-20T22:32:15+00:00 URL: https://externals.io/message/96993#97094 · In reply to: #97080 > 2016-11-19 22:56 GMT+01:00 Rowan Collins : > > […] > Yes because that has been our past model for a long time. Like I > mentioned, PHP 5.3 should probably have been a major considering the > changes it did. Agreed that it's the past model, and agreed that 5.3 was misnamed whichever way you look at it. The fact that something used to be done a particular way doesn't mean that was the best way, though. It's also not what the current release process specifies, in my opinion. > It wasn't until PHP 5.3 that we introduced > E_DEPREPCATED and actively started taking out problematic features > which in the past had caused issues with the usual group of people who > don't care to read the manual, so we gave those features a little > longer life span while informing the developers that we are gonna > remove it. > > Basically before we started to get all political of things I'm not sure what you mean by "political". The big challenge which comes up again and again, is that take up of new versions of PHP is low. You can blame the users for that if you like, but the reality is there's no point rushing your shiny feature into a release that 90% of the user base won't install. Well-publicised deprecations, and a strict adherence to compatibility, build trust that upgrading won't be a major headache, meaning new features actually get to users *faster*. And to return to the topic at hand, knowing how long something will be deprecated before it's removed helps people plan ahead. > If we were to rename past releases to a scheme by SemVer, then that > would pretty much have been a yearly major, that is extremely poor > versioning in my opinion when we retrain such a high backwards > compatibility rate otherwise. If every release contained breaking changes, then the release process RFC has failed. It would be extremely poor versioning not because we'd somehow run out of version numbers, but because it means we've made upgrading harder than it should be. Let me quote that SemVer FAQ in full: > /Q: //If even the tiniest backwards incompatible changes to the public > API require a major version bump, won’t I end up at version 42.0.0 > very rapidly?// > // > //A: This is a question of responsible development and foresight. > Incompatible changes should not be introduced lightly to software that > has a lot of dependent code. The cost that must be incurred to upgrade > can be significant. Having to bump major versions to release > incompatible changes means you’ll think through the impact of your > changes, and evaluate the cost/benefit ratio involved./ In reality, we had two very successful minor releases after the release process was agreed: 5.5, and 5.6. I think 7.1 has bent the rules, and I think that's a shame. > I don't like the thought that PHP 5.4 > could have been PHP 6 just because we removed safe_mode, that was > deprecated in 5.3. That would be a disappointing reason just to go for > a new major. Agreed, so the answer would be not to remove it yet! If it was really that urgent to remove the feature, then yes, bump the version number to say so; if it could wait for one more minor release, then let it wait. It's an odd example though, because for me by far the biggest break in 5.4 was the removal of call-time pass-by-reference, which was widely used, and very fiddly to remove. But the story of 5.3 and 5.4 is inextricably tied up with the failure of 6.0, so we can come up with all sorts of "what if" scenarios and prove very little about the present and future. > Same as above, I dislike this rapid jumping in versioning. Though this > is my personal opinion, for me as a Core Developer of PHP, I prefer > this scheme as it makes sense to me as it is pretty much what it > always has been. That's fine, that's what I mean by "version number as branding". But if we go down that route, we should drop all reference to major versions in our deprecation and compatibility policy, because that's a fundamentally different meaning of "major". For instance, we could have a fixed duration of deprecation, say deprecated for 2 versions, removed in the next. So any features deprecated in 2017's release would be removed in 2019's release, regardless of its version number. In 2018, further features could be deprecated, to be removed in 2020, and so on. > > […] > I don't think that will work as most people when you say the Zend > Engine that is not into the PHP.net project will maybe know that its > the core of PHP, but nothing more about it so I don't think it makes > much sense to suddenly start label releases as such. Sure, I was just brainstorming alternative solutions, since we seem to have very different ideas of what the version number is there for. Ignoring "Zend Engine" in particular, think about Windows prior to 10: the internal (kernel) version number had strict rules, and the marketers could make up whatever name they liked, meaning Windows 7 and 8 were both internally 6.x. Regards, -- Rowan Collins [IMSoP] --- ## #97095 — Derick Rethans — 2016-11-20T22:42:28+00:00 URL: https://externals.io/message/96993#97095 · In reply to: #96993 > Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. I wouldn't deprecate things that 1. have no replacement, 2. are very much in use, or 3. are harmless. __autoload is one of group (2). I think this is used a lot, and would *not* want to deprecate this until PHP 8. I also do not see why (binary) should be removed, as it fits in category 3. In general, I think you should have a good reason *why* to remove them, and just "it's not what we suggest you use" is not good enough. It should be a general *bad* thing, before it should be considered for removal. Right now, the only thing I can think of is removing mbstring.func_overload. For ini settings, you should not throw a deprecation warning if the setting is set to *off*. This covers mbstring.func_overload , but it seems you have changed that since I read this RFC for the first time. cheers, Derick --- ## #97096 — Daniel Morris — 2016-11-20T22:50:54+00:00 URL: https://externals.io/message/96993#97096 · In reply to: #97095 > __autoload is one of group (2). I think this is used a lot, and would > *not* want to deprecate this until PHP 8. Agreed, I still think this is used widely, it would be fine to have it throw an `E_DEPRECATED` in 7.2 and removed in 8.0. Upgrading to not use __autoload would be trivial. > I also do not see why (binary) should be removed, as it fits in category > 3. Whilst (binary) may be harmless, it's also pointless, since it's just an alias for (string) – I don't think it has wide-enough usage to worry about deprecating it sooner rather than later. -- Daniel Morris daniel@honestempire.com --- Next page: https://externals.io/message/96993.md?page=2