[RFC] [Discussion] Minor version compatibility

Hey Jorg,

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

Hi,

Thank you all for the feedback on the topic of BC breaks in argument
validation https://news-web.php.net/php.internals/126706

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

Since this touches on the broader topic of release policy and BC
expectations, I’d also like to open the door for related improvements.
Rowan raised several valid points that highlight the need for clearer
communication and expectations around minor version changes. If the
community feels it's appropriate, I’m happy to include these suggestions in
the voting. The more clearly BC policy is defined, the less time we’ll need
to spend on debating individual cases in the future.

Rowan’s suggestions included examples like:

Maybe we could work on some criteria that could be applied (and publicised
to users) about what is and isn't allowed in minor versions.
For instance:

Code that already causes fatal behaviour might cause different fatal
behaviour (e.g. throwing an Error instead of raising an E_ERROR)

Code that directly violates documented types might start throwing
TypeError

Code that previously returned null for invalid inputs might start
throwing ValueError

This looks a bit too generic to me and it might significantly differ based
on use case as Bob noted. I think we should leave some flexibility and
rather add rules for specific issues where we need some defined approach.
In this case it is handling of errors for cases where only constants are
documented.

Kind regards

Jakub