On Tue, 16 May 2023 at 12:03, G. P. B. <george.bany...@gmail.com> wrote:
> > 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). > Again, the solution to "people don't like deprecation messages" is not "don't deprecate things", it's "improve how deprecation messages work". There should be absolutely zero reason not to deprecate something in an X.0 release, or even in an X.0.15 release, because a deprecation message form the code should serve the same purpose as, and have similar impact to, a note in the documentation. > 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. > I don't think that's what anyone's saying. They're saying that if we have a predictable release cycle, we can decide for each case between a one-to-two-year deprecation, and a five-to-six-year deprecation. If we don't have any idea when PHP 9.0 will come out, then we can't even begin to discuss that, we have to say "the deprecation period will last anywhere between one year and ten years, depending when we get round to a major release". I don't think that helps anybody. > 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". > Having a fixed release cycle actually allows this to be turned around to something more productive: "we could consider this for PHP 9.0, which will happen in 2 years time". Without it, all we can say is "we could consider this for PHP 9.0, but you have to regularly read the internals mailing list for several years to get a hint of when that might be". Note that prior to PHP 5.4, we had this same "when things are ready" approach to tagging *any* release. Since then, we've had an annual release cycle, which I think has worked well in terms of both contributors and users being able to plan ahead. 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. > I mentioned JIT, because around this time in the 7.x life cycle, I was regularly having this same debate, and people used "everyone knows PHP 8 will be whenever the JIT is ready" as though it was more important than any other planning we might want to do. I disagreed then, and I disagree now. > 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. Given that we changed a whole list of resources to objects in PHP 8.1, it's clearly not considered that massive a shift to most people https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.resource2object Regards, -- Rowan Tommins [IMSoP]
