On Monday, 9 March 2026 at 15:53, Christian Schneider <[email protected]> wrote:
> Am 09.03.2026 um 14:36 schrieb Gina P. Banyard <[email protected]>: > > I don't see how going through an E_WARNING phase is helpful, rather I see > > it as detrimental. > > Foremost, what is the behaviour of introducing a warning? > > Do we exit early and return false? > > Or do we just warn and continue to use a possible default or nonsensical > > value? > > in all the previous cases where we deprecated things we continued to leave > the behaviour unchanged apart from issuing the warning. > > > AFAIK every time a warning got introduced it followed the first approach, > > so this doesn't seem to address the concern of giving developers more time. > > Replace E_WARNING in your phrasing with E_DEPRECATED and your statement > becomes obviously false. > If that's the differentiator for you then I'm happy to have an E_DEPRECATED > phase before throwing a ValueError exception. These are not similar to deprecations. In these instances you have a silent bug that is being suppressed, and you should be aware of it loud and clear. A deprecation is a mechanism to indicate that previously *valid* and bug free code is getting phased out. These are fundamentally two different situations, thus I disagree that they should use a deprecation. > > > However, if we do continue using the prior behaviour then we haven't solved > > the concern in the slightest. > > As it may be a warning for one PHP version and in the next PHP version the > > extension supports a new flag which removes the warning for that value, > > leading back to a silent BC break if the warning wasn't addressed. > > Nothing can protect you from old code using a new flag by accident. Imagine > someone skipping the version with the ValueError and going directly from 8.5 > to the version with added flags. That's not the scope here. > > > Then comes the topic about how long should it be a warning? Until the next > > major? A single release cycle? I don't want warning promotion to become the > > same exhausting discussion that deprecation duration already is. > > In my view it is *exactly* the same as deprecations and should be handled as > such. > I'm on your side here that I don't want yet another process and that's why > I'm advocating the IMHO tested and proven solution we are using for > deprecations. As mentioned before I disagree that this is like a deprecation. > > I have no idea how you handle hosting, but when I used shared hosting in > > the past I would never have anyone tell me that my code was producing > > warnings or notices. > > And even the one website I manage for someone which is on OVH shared > > hosting I can still select a PHP version (heck even downgrading to 5.4 for > > some reason). > > So I'm struggling to see how for the average end user this is impacting > > them? > > I'm supporting applications running on hosters where they bump the minimal > supported version quite often. > "Works for me" is hardly ever a strong argument... This then seems to be self-inflicted problems from these specific hosters. Unless they take the QA responsibility to ensure the migration works, just blindly upgrading PHP's version seems frankly irresponsible. Best regards, Gina P. Banyard
