Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79774 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84196 invoked from network); 17 Dec 2014 12:12:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2014 12:12:54 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:44535] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1C/31-10120-44371945 for ; Wed, 17 Dec 2014 07:12:54 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 7F88010C019; Wed, 17 Dec 2014 12:12:49 +0000 (GMT) Date: Wed, 17 Dec 2014 12:12:49 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Ferenc Kovacs cc: Zeev Suraski , Julien Pauli , Florian Margaine , Rowan Collins , PHP Internals In-Reply-To: Message-ID: References: <8C1EFD82-CFE0-4D01-9231-2A1658B182A6@ajf.me> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] [RFC] PHP 5.7 From: derick@php.net (Derick Rethans) On Tue, 16 Dec 2014, Ferenc Kovacs wrote: > > > - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not > > > new features cancels point number one > > > > > > What else ? > > > > Do nothing is still (IMHO) the most sensible option IMHO. We're not > > seeing major compatibility breakages in 7.0 (at least not at this > > time), to the level that upgrading through some middle version is > > really all that necessary. > > we don't have much or really big ones(yet), we have a couple of nasty > ones (eg. doesn't blow up, but behaves differently, check the mails > from Derick complaining about those). Those should never have made it into PHP 7 at all. It's like a big "fuck you" to users. > and there are a couple ones upcoming/likely to make it through: > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 I think we should bump up the granularity of the voting options there. As some I think are ok, for example: - dl on fpm-fcgi (since PHP 5.3) But others are not: - CN_match and SNI_server_name stream context option (since PHP 5.6; use peer_name instead) [TODO] > > The one option that could be relevant to these scenarios is a > > separate analysis tool, but it's much more difficult to pull off, > > and I don't think the level of breakage (as it appears right now) > > justifies the effort. > > fortunately we already have a couple of those for some of the nasty changes > like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code > which would be affected by the behavior change of > https://wiki.php.net/rfc/uniform_variable_syntax > I do think that while those kind of extra steps are not mandatory per se, > but they help a lot when convincing people to jump the ship and upgrade. I would go as far as making it mandatory if you change bahaviour of existing syntax that can't be detected through a simple "php -l". cheers, Derick