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