Hey Jorg,
On 13.4.2025 23:07:07, Jorg Sowa wrote:
I have collected all concerns, prepared an RFC for this change, and
I'm opening discussion on its content:
https://wiki.php.net/rfc/minor-version-compatibility
Let me address some parts of the RFC:
- The secondary vote #1 requires the same handling for everything. I
don't think that's a wise choice.
There may be cases where keeping an E_WARNING (not E_DEPRECATED
though) may be acceptable.
There may be recently (e.g. last minor) introduced APIs, which, by
oversight, accept unexpected inputs. It may be decided that it would be
too much of a compatibility break to "fix" this in a bugfix version.
However, it should be possible to decide to fix this straight ahead in
the next minor, rather than waiting for the next major. Especially for
recently introduced features, having deprecation periods of possibly 4
years, when they were only introduced the year before, is a bit excessive.
- The secondary vote #2 requires that you either select E_DEPRECATED or
E_WARNING. That's not right. E_DEPRECATED may be a precursor to E_WARNING.
There's no silver bullet on what exactly is to be chosen.
E_DEPRECATED is for something which will change, but is generally not
problematic in existing code. E_WARNING is for something which *may*
change and is probably problematic in existing code.
This though means that there will be cases where there's ambiguity.
That's fine. Reach a soft consensus and then go ahead with that.
I don't fundamentally disagree with the attempt to codify something
here, but ultimately the PHP language does and will continue to profit
from some flexibility in these regards.
I think, with the choices, we've actually ended up making in the last 12
years (essentially since PHP 5.5), users haven't been surprised too much.
At least also anecdotally from my experience - upgrading old code is
perfectly fine to do with last minor -> first minor -> last minor -> ...
upgrades.
New code is not fine to do such major jumps. Semantics of code using
brand new features is improved sometimes. Bugs are fixed. Things end up
slightly different. That's fine though. If you want to live on the edge,
that's the price you pay for this. Being able to rectify freshly
introduced mistakes and inaccuracies quickly is important for the health
of the language.
Please, while it's sane sounding, let's not codify too much of
black-and-white policies.
Thank you,
Bob
