Hi
Am 2025-05-13 12:13, schrieb Jakub Zelenka:
From my experience in maintaining an old PHP application and
upgrading
it to support the latest and greatest PHP every year, I think the
following points would be a good starting point to discuss:
- For backwards compatibility breaks introduced in minor versions
there
MUST be a simple (for some appropriate definition of simple) way to
adjust the code to be compatible with both the current PHP version and
the upcoming version. Ideally the change would be compatible with a
wider range of past PHP versions (past 3 or so?). It must be a change
that is simple to perform even with basic tooling (i.e. not requiring
an
IDE or static analyzers).
If I understand it correctly, this sounds really more like completely
new
rule that we don't currently have so I would rather not add it. We
don't
have this relation differences between X.Y and X.(Y+2) to do some extra
breaks so it's more for a separate RFC. I'm also not a big fan of such
change to be honest.
We don't currently have any rules at all, except for “when the RFC
approves the break, then it's okay”. I was trying to find some guideline
for BC breaks that might be okay in a minor (when approved) and BC
breaks that are never okay in a minor.
The application in question is in a very similar position that PHP
itself is, it has a large public API that "third party" developers rely
on and a long development history. BC breaks sometimes are not avoidable
when you try to move forward. Basically the rule of thumb for a breaking
change in a minor version was that "most third party add-on should be
adaptable with minimal changes, while remaining compatible with both
minor versions after making these minimal changes".
Adding new symbols results in a compile time error (immediately
obvious)
and is simple to fix (rename or remove your own implementation).
Similarly throwing a ValueError for invalid inputs is reasonably easy
to
detect by executing the affected code path (you can't miss an
Exception)
and also simple to fix (don't do that). Changing operator precedence
is
not easy to detect, thus it is unacceptable. Throwing an error when
single-letter variables (e.g. $i) would be easy to detect, but break
almost every program, thus would be unacceptable.
This makes sense but might be a bit too specific. Did you mean to also
include it in this policy?
That paragraph is intended as an example for my train of thought / how I
would interpret my suggested guidelines for hypothetical breaking
changes. Of course I do not expect anyone to propose an RFC to disallow
single-letter variables (not even in a major).
Best regards
Tim Düsterhus
