Re: [RFC] [Discussion] Deprecate functions with overloaded signatures
| From: | Larry Garfield | Date: | Mon, 15 May 2023 18:38:56 +0000 |
| Subject: | Re: [RFC] [Discussion] Deprecate functions with overloaded signatures | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120296@lists.php.net to get a copy of this message | ||
On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
> On 15 May 2023 09:54:41 BST, "G. P. B." <george.banyard@gmail.com> wrote:
>
>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>
> Historically, PHP has had a major release roughly every five years. The
> main exception is PHP 6, which was never released - but whose major
> features became PHP 5.3, five years after 5.0, and six before 7.0
>
> I think planning a rough timeline is more useful to users and
> contributors than waiting until there's some exciting headline feature.
> Otherwise, it becomes tempting to sneak in breaking changes in 8.x
> because "we don't know how soon 9.0 is", or to have a rush of changes
> because "we've only just decided 9.0 is soon".
>
> It also helps avoid putting a release number on an experimental feature
> that might never arrive, as with Unicode strings in 6.0; or that might
> turn out to be less important to most users than other changes, like
> the JIT in 8.0.
I agree entirely. Setting reasonable expectations for users to plan around, such as a known
5-years-per-major cycle, helps end users far more than "whelp, we did something big, version
number time!"
Tangent: If I were to put together an RFC that set out such a 5 year cycle expectation with
reasonable guidelines around when things could be deprecated, would anyone actually support it?
--Larry Garfield