On 6/14/2016 9:43 PM, Stanislav Malyshev wrote: > Changing notice to warning is a breaking change too :) And I'm not sure > how rushing 8.0 helps anything if you're afraid of breaks - you get > useful features later but also bigger breaks. Long term it doesn't > matter anyway unless 7.1 is somehow special, which is not. Also, having > just two minor versions seems to be a little thin, unless there's a plan > to keep maintaining 7.x, in which case the question is - who's going to > do that? >
On 6/12/2016 6:42 PM, Rowan Collins wrote: > Here is where things begin to get subjective, but the following seem > reasonable to me, and seem to match most decisions made up until now: > > - Notices, Warnings, etc, may change severity, but must not become > Errors or Exceptions. > Quote from the initial message. There is no breakage by elevating an E_NOTICE to an E_WARNING because the script continues to work without anything. Yes, there might be a log entry from now on or (worse) a custom error handler that is now going to jump in. As we all agreed upon, not everything is avoidable and this particular RFC might even be okay (I actually agree with all your reasoning but am still highly afraid of the BC impact). It does not change the general topic being discussed here. Nobody said to release 8.0 right away but to start planning it. Also, if there are enough changes pilled up to justify a new major than there is nothing that speaks against only a few minor versions. The current approach to release a major every 10 years is also weird. After all, PHP did not mature as much as e.g. C or C++. Java 9 and 10 are also already planned: https://en.wikipedia.org/wiki/Java_version_history#Java_SE_9 Personally I think ignoring any BC promises is much more severe than having another major pretty fast. The latter at least does not come as little surprise box and clearly communicates what it is. Many projects also have various release flavors to better cope with such situations where developers feel blocked by the restrictions of BC. Maybe that could be something for PHP too? Having a PHP 8.0.0-alpha.1 or 8.0.0-preview.1 that is released like our current minor releases. People who feel adventurous may use it as is since it is stable but its API is not and any upgrade may contain breaking changes. The 7.x.x stable branch is continued being developed but all breaking changes go into the 8.0.0-x.x mainline branch (an appropriate action is taken in the 7.x.x stable branch like here with the raising from E_NOTICE to E_WARNING). Note that completely new features can directly go into both. Nginx has a similar approach for instance, but so does Debian. This "problem" is solvable and ignoring it or talking it down does not help anyone! :) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
