On Fri, Mar 20, 2015 at 5:04 AM, Nikita Popov <nikita....@gmail.com> wrote: > On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski <z...@zend.com> wrote: > >> > On 19 במרץ 2015, at 19:40, Dan Ackroyd <dan...@basereality.com> wrote: >> > >> > You are being dumb here as well. We try to avoid breaking code in >> > point releases. This BC break can only be done at a major version. >> >> Technically, we're not allowed to move from from a working feature into a >> removed one without a deprecation phase. >> > > I don't think this is true. There is no requirement for us to deprecate > something before we remove it. Deprecation is a courtesy to our users in > cases where a heavily used feature is being dropped.
I think we do not need to argue about the impact of having something generating a fatal error all of a sudden in 7.1. Or am I missing something? :) > Realistically most people consider E_NOTICE to be a higher error level than > E_DEPRECATED. If somebody is willing to suppress the notices this currently > generates, chances are very high that deprecations are suppressed as well. > I don't see any release process issues with dropping this without > deprecation. (But I'm still -1 on the change, because I don't see why we'd > suddenly want to change this one relatively unimportant notice to be fatal > while leaving everything else alone.) Same, if anything doing fatal then it has to be done in 7.0. Also I have to agree with Zeev on that, a warning or deprecation notice should be enough. I know it is not what many users want, to clean up such things, but we decided not to have a 5.7 to prepare such removals, let act accordingly. cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
