Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61055 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94307 invoked from network); 30 Jun 2012 22:59:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jun 2012 22:59:41 -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 67.192.241.173 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.173 smtp173.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.173] ([67.192.241.173:35520] helo=smtp173.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/25-58870-CD48FEF4 for ; Sat, 30 Jun 2012 18:59:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 12FF51889CD; Sat, 30 Jun 2012 18:59:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp17.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 81C3F1884F9; Sat, 30 Jun 2012 18:59:37 -0400 (EDT) Message-ID: <4FEF84D8.20107@sugarcrm.com> Date: Sat, 30 Jun 2012 15:59:36 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikita Popov , =?ISO-8859-1?Q?Johannes_S?= =?ISO-8859-1?Q?chl=FCter?= , Pierre Joye , David Soria Parra CC: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: JSON changes in 5.3/5.4 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! I see that there were significant changes committed to JSON extension in 5.3 and 5.4 recently. These changes modify json_encode behavior, break tests (pass001.1_64bit.phpt does not work anymore for me), are not clearly documented and have no NEWS/UPGRADING entries describing what exactly changed, had no RFC, use new function with name inconsistent with all existing functions with the same semantics (json_last_error_msg) and IMO do not belong in stable branches, especially not done this way. I intend to release 5.4.5 RC1 next week, and I want this matter to be cleared up before that, because I can not release it in this state. So we have two options here: 1. Revert everything to 5.4.4 state and deal with it in 5.5 or maybe in 5.4.6 if it'd be ready. 2. Have it cleaned up ASAP and brought to a state where there are no test failures and there's a clear description of what the changes were in NEWS and UPGRADING. I think option 2 is better, but if it can not happen by EOD Tuesday (July 3) I intend to go with option 1. Nikita, please advise how you prefer to proceed with this. Johannes, do you want me to revert it in 5.3 branch too in case we have to go with option 1? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227