Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

From: 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

« previous php.internals (#120296) next »