On Mon, 15 May 2023 at 19:36, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 15 May 2023 09:54:41 BST, "G. P. B." <george.bany...@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 totally agree that we shouldn't use a major number as an exciting feature flag. However, if what we want is a consistent timeline for how long something gets deprecated before being removed, then let's just do like Python and state that the deprecation exists for two consecutive releases and will be removed in the third one. Because this proposal of "let's do majors every 5 years" now reduces what we can do, as we cannot (or should not) deprecate stuff in X.0, as it makes it harder for people to upgrade to the new major (see how we postponed the 8.0 deprecation RFC to 8.1 after various comments). But apparently we cannot deprecate anything in X.3 or X.4 because there will "never" be a X.5 again and this is "too short" of a time frame. This, IMHO, is terrible for the project's maintenance. As this basically says to someone who wants to start contributing to the project by deprecating some weird behaviour that they may be told off with "you should have done this X years ago" or "wait another Y years". People cannot magically know when they should shove aside any other priorities in life just to be able to make *some* change to the language. Considering, this was partially the argument used against Max Kellerman with the header changes: "this should have been done for PHP 7.0 or PHP 8.0". Those sorts of statements alienate new (and old) contributors, and looking at the state of the projects where we are still very much thin on maintainers, anything that does this is from my POV a no-go. My understanding as to *why* the JIT caused the major bump was because of major changes within the Zend Engine, not necessarily the feature in itself. And again, the only "good" reason I see for a major bump is something like converting streams from resources to objects, as this is a massive shift and has the possibility to cause issues for a lot of codebases. Best regards, George P. Banyard
