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.
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?".
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.
- Are there any things being worked on that would deserve or require a
major version bump in PHP?
I think there are two conflicting ideas of what a major version should be:
a) A major version is an ad hoc event that happens when something
"significant" is being changed. Any other breaking changes can piggy-back
on that major change.
b) A major version is part of the general life cycle of the project. It is
a periodic chance to make breaking changes that were held back from annual
releases.
Under (a) deprecations have no predictable duration; they will become
breaking changes whenever the opportunity arises because of a completely
disconnected decision. On the other hand, a major change can be started at
any time, with the release timeline adjusted to fit its progress.
In (b) there is a fairly clear expectation of how far away a breaking
change is once a deprecation is agreed; contributors can use this to decide
if that timescale is adequate, and users can use it to plan how to handle
the change. On the other hand, a major change faces an increased risk of
missing the major release window, and either being rushed or being held
back for several years.
I'm not convinced major changes that would run into problems with (b) are
all that common; many major features are delivered within the annual
release cycle, and many breaking changes in x.0 versions don't require a
long lead time.
A compromise might be to have a planned cycle, but with some leeway for
major projects, e.g. "a major release will happen no more often than every
4 years, and no less often than every 6"; or, to put it a different way,
"there will always be an x.3 release, and never an x.6".
Regards,
Rowan Tommins
[IMSoP]
[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.
Userland here and I agree with you completely. My opinion is that the maintainers should decide, since they bear the burden of the decision.
-Jeff