Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68467 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92683 invoked from network); 9 Aug 2013 16:53:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Aug 2013 16:53:07 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:48499] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 44/02-06453-27E15025 for ; Fri, 09 Aug 2013 12:53:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A53D5501D9; Fri, 9 Aug 2013 12:53:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 5304850177; Fri, 9 Aug 2013 12:53:04 -0400 (EDT) Message-ID: <52051E71.9010309@sugarcrm.com> Date: Fri, 09 Aug 2013 09:53:05 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yasuo Ohgaki CC: Lester Caine , PHP internals References: <5202FC8A.2070307@sugarcrm.com> <52035622.1090301@lsces.co.uk> <52038ABF.8060904@lsces.co.uk> <5204B690.4060006@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] "php_serialize" session serialize handler From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > As I wrote, there is no real BC issue as it's just a matter of ini setting. There is a BC issue if you need an ini setting. You keep dismissing it but if it affected the app your business relates on it'd be a major problem if on upgrade your app breaks and you need to scour release notes to figure out all settings you need to change for each upgrade. So we try to minimize such cases. In some instances, it's unavoidable - but in this case, the support for numerics in _SESSION is an exotic feature that will be of little use for 99% of PHP users. So introducing additional upgrade headaches for this is IMHO unnecessary. > I'm not going to remove old one, though. Search bug db, there are many > bug reports/feature requests that this patch solves. How many bug reports are there requesting numeric index support in session? > If users aren't reading release note of minor version up, then it is users' > fault, > not ours. If it is, we cannot release new PHP. We can. We can also take some responsibility for making it easier to upgrade and not just say "we had it all in the fine print, it's your own fault for not reading everything". Vendors that do that are usually disliked by their customers. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227