Hi Marco 2016-11-19 18:56 GMT+01:00 Marco Pivetta <ocram...@gmail.com>: > 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
