Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.195 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
Date: Sat, 19 Nov 2016 18:42:10 +0100
Message-ID: <CAJW__o2ffCSRPTZ+QojSBoL6YA0ZgP_iGtW00WHD104aCziWEg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: kalle@php.net (Kalle Sommer Nielsen)

Hi Rowan

2016-11-19 18:23 GMT+01:00 Rowan Collins <rowan.collins@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
kalle@php.net