On Sat, 13 May 2023 at 00:08, Larry Garfield <la...@garfieldtech.com> wrote: > > I am actually tempted to propose that we do deprecations at the very > start of a release, 9.0 and 9.1 only, and then not allow them for the > rest of that major, for that exact reason.
That sounds really unwise. People aren't that enthusiastic about volunteering to work on things that would take 5 years to deliver a change. It would make maintaining PHP be a lot harder, and also be a burden on core maintainers. On Mon, 15 May 2023 at 09:55, G. P. B. <george.bany...@gmail.com> wrote: > > Why are we assuming that PHP 9.0 is going to come after PHP 8.4? Partly because I experience time linearly? And afaik, no-one has a lot of negative emotional feelings about the number 9. But I guess maybe you meant, "why are people assuming PHP 8.5 won't exist?". On Mon, 15 May 2023 at 19:39, Larry Garfield <la...@garfieldtech.com> wrote: > > 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? I think that would cause more drama. IMHO, you seem more attracted to having processes and schedules written down, than core devs appear to.[1] Although we should probably discuss when major releases happen, we should start that conversation off by asking questions. I've only been taking part in internals discussions for two major releases, and it's pretty unclear to me how the decision to stop releasing on the 5.x and 7.x branches was made. I would appreciate any core contributors[2] thoughts on any of the following: * Are there any things being worked on that would deserve or require a major version bump in PHP? * In particular, should we expect PHP 8.5 to be a thing, or should we expect PHP 8.4 to be the last release of the PHP 8.x branch? * Is there, or could there be, a process for planning when the next major release is going to happen? Or would requiring volunteers to plan their volunteering multiple years in advance be too much of a burden? cheers Dan Ack [1] I agree with the people who actually do the maintenance here. Fixed processes don't actually help that much on a project the size of PHP. Most of the time people are sensible and can be reasonable about things, even if their priorities aren't the same as other people, and so to outsiders they don't appear as reasonable. [2] I am sure lots of userland people and other people will have opinions also. I just don't think they will be as insightful or useful in this conversation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
