On Fri, Mar 20, 2015 at 5:04 AM, Nikita Popov <[email protected]> wrote:
> On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski <[email protected]> wrote:
>
>> > On 19 במרץ 2015, at 19:40, Dan Ackroyd <[email protected]> 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