Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.153 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=oQSeA217wr7T0IqqRR1bOs79Nt+nzyYe+MnfG+XlSJ0RXDLUNEXG7pAtTWYVjkECBv
         wBjUCaGxXpoc4bEwTAUVvKyWuUTaUMz3c/JW6+Ww+en+36F5COQhuq0L2TdR5fESIYpQ
         /eu4ZbUmMlmpa4opSZcS+0reeW0QIpx3Xm6aw=
Message-ID: <4BC9AAC9.7000008@gmail.com>
Date: Sat, 17 Apr 2010 14:34:17 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100416 Lightning/1.0b1 Shredder/3.0.5pre
MIME-Version: 1.0
CC: internals@lists.php.net
References: <n2k2dedb8a1004081548g4381879ahb76cf5ab9b855a9d@mail.gmail.com>	 <1271408519.4615.89.camel@guybrush>	 <q2jb54d0abe1004160323v54f8aad1j3f7817d4ff96507d@mail.gmail.com>	 <201004161538.23534.larry@garfieldtech.com> <s2pb54d0abe1004162239p356d647cq1d29800f0a06ae5b@mail.gmail.com>
In-Reply-To: <s2pb54d0abe1004162239p356d647cq1d29800f0a06ae5b@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Removal of deprecated features
From: pasthelod@gmail.com (Pas)

On 2010.04.17. 7:39, Ferenc Kovacs wrote:
> On Fri, Apr 16, 2010 at 10:38 PM, Larry Garfield<larry@garfieldtech.com>wrote:
>
>> On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote:
>>
>>> I think that the hosting providers will do notice, and either not
>> migrate,
>>> or send a mail to their users, warning to check their settings because if
>>> they are depending on the magic quotes, they will be in danger.
>>>
>>> So I think we don't have to wait for the shared hosting providers,
>> because
>>> they will catch up as slow or fast as we go.
>>
>> Given how long it took them to catch up to PHP 5 in the first place I don't
>> think we can count on that.
>>
>> Because PHP4 was supported for a long time. This is what I'm saying. If you
> support 5,3 at least with security updates for years, they won't  upgrade
> because they don't have to.
>
>
>> Such breakage should come in large chunks so that hosts only have to wring
>> their hands once every so often.  Otherwise they just won't upgrade ever.
>> Most run on very thin margins.
>>
>>
> I disagree, from the point of the coder who has to port the application from
> one version to other, it's easier, if there is only a few changes, which has
> to be taken care of.
>  From the point of shared hosting providers, they don't want to change
> anything from the BC perspective, so if you turn off some default value, or
> throw deprecate warning, they will turn it back on, and ignore the errors.
> When this is not possible (because you removed some feature), they won't
> upgrade, as long as there is security support for the old version.
>
> Tyrael
>


Just some anecdotal evidence regarding this issue:

http://it.slashdot.org/story/10/04/16/1646244/ClamAV-Forced-Upgrade-Breaks-Email-Servers 
<http://it.slashdot.org/story/10/04/16/1646244/ClamAV-Forced-Upgrade-Breaks-Email-Servers>

The 2 year old version of the ClamAV daemon (0.94) is incompatible with 
the new signature updates (for the also free 0.95 and 0.96 versions), so 
the old version crashed.

The funny part is ClamAV was announcing this for at least 6 months. On 
mailing lists, their homepage, plus the daemon was flooding the server 
log every day with warnings.

Still, some admins did not care about a product that couldn't be more 
explicitly a factor of their network security. Therefore, in my opinion, 
waiting for admins to upgrade is futile, useless, and just keeps users 
in security-fairyland for more time.

Pas