Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53935 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2049 invoked from network); 13 Jul 2011 18:21:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jul 2011 18:21:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:59693] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4C/71-24992-212ED1E4 for ; Wed, 13 Jul 2011 14:21:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9C9B23C839C; Wed, 13 Jul 2011 14:21:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 53BCB3C839B; Wed, 13 Jul 2011 14:21:02 -0400 (EDT) Message-ID: <4E1DE20E.20902@sugarcrm.com> Date: Wed, 13 Jul 2011 11:21:02 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ferenc Kovacs CC: Philip Olson , PHP Internals References: <4E17F5A0.3070409@sugarcrm.com> <4E1B9343.3090000@sugarcrm.com> <967B58EB-C704-40CD-AFEE-D0CA2192F4FA@roshambo.org> <4E1DC072.8080300@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] 5.4 features vote From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 7/13/11 11:11 AM, Ferenc Kovacs wrote: > I would also change my vote, I would go with keeping it deprecated, > but turning it off by default (currently it isn't done, but the > suggested development/production inis have this turned off), and > remove it with the next minor version bump. Which basically means doing nothing, as the effective default is the recommended INIs, where it's off. So what would change before now and then that makes it inacceptable to remove it now but acceptable to remove it then? > hopefully the security documentation will be in the better shape and > we can figure out how to communicate such changes better to minimalize > the impact. Our abilities to communicate will probably be in 1 year exactly as they are now, unless there's some big project to improve it that I'm not aware of. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227