Hi, On Sun, May 11, 2025 at 10:14 PM Tim Düsterhus <t...@bastelstu.be> wrote:
> Hi > > I gave this some additional thoughts. > > Am 2025-05-09 13:36, schrieb Jakub Zelenka: > >> - A minor version MUST NOT break syntax compatibility (i.e. every PHP > >> program that compiles must continue to compile). > >> > > > > Added this one > > Thinking about this more, I am not sure if having this as a MUST rule > matches what we did in the past and I'm also not sure if it is useful to > have. This rule prevents the addition of new keywords, since they might > conflict with function names. Adding new symbols and adding a new > keyword is functionally equivalent, both changes would result in a > compile time error. Singling out the syntax change does not appear to be > a useful distinction. > > Yeah this make sense. I changed it to SHOULD in the latest version with some other updates. > -------------------------- > > 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. > - Backwards compatibility breaks in minor versions MUST NOT result in > silent behavioral differences. Instead any breaking change must be > "obvious" when executing the program, even when having a > less-than-stellar test suite. > > I think this makes sense and added this paragraph (with exception of that less-than-stellar test suite) to the policy. > 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? Kind regards Jakub
