Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93945 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35074 invoked from network); 13 Jun 2016 17:46:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jun 2016 17:46:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:47590] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 09/A0-12403-B81FE575 for ; Mon, 13 Jun 2016 13:46:52 -0400 Received: from cable-81-173-133-15.netcologne.de ([81.173.133.15] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bCVwm-0006lP-Aa; Mon, 13 Jun 2016 17:46:48 +0000 Reply-To: internals@lists.php.net References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com> <020a01d1c501$3d3d9420$b7b8bc60$@php.net> To: Joe Watkins , Rowan Collins Cc: Anatol Belski , Ferenc Kovacs , Joe Watkins , Davey Shafik , PHP Internals Message-ID: <171ab79f-7e52-b485-351d-7efe312589b1@fleshgrinder.com> Date: Mon, 13 Jun 2016 19:46:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJxPeKWhaCBf20uf8uJICSRaO4trmoFWN" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable? From: php@fleshgrinder.com (Fleshgrinder) --IJxPeKWhaCBf20uf8uJICSRaO4trmoFWN Content-Type: multipart/mixed; boundary="3q878V6P5rK95F7kniObLiAgokmEFAUV8" From: Fleshgrinder Reply-To: internals@lists.php.net To: Joe Watkins , Rowan Collins Cc: Anatol Belski , Ferenc Kovacs , Joe Watkins , Davey Shafik , PHP Internals Message-ID: <171ab79f-7e52-b485-351d-7efe312589b1@fleshgrinder.com> Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable? References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com> <020a01d1c501$3d3d9420$b7b8bc60$@php.net> In-Reply-To: --3q878V6P5rK95F7kniObLiAgokmEFAUV8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/13/2016 4:32 PM, Joe Watkins wrote: > You can count the number of people putting in the majority of this effo= rt > on your fingers ... erecting a road block in front of them in the name = of > unobtainable BC is harmful to the apparent goals of the project at this= > time. >=20 The work of these people is highly appreciated and actively as well as publicly admired by the whole community. This is a fact. That being said, this is not about erecting a road block in front of them. This is about the same rights for all, something that is important in a community, especially in a community without any kind of leadership.= Nobody is allowed to fix inconsistencies on an API level due to BC concerns. Nobody is allowed to renamed some constants (T_PYJAMA_NEKO anyone?) due to BC or nostalgic concerns. Yes, that stuff is mainly cosmetically. Yes, that stuff does not require the super magic skills that our engine gurus possess. Yes, you can count the people capable of doing any of this stuff on many hands. However, the rules should be the same for everyone in regards to BC. The rules should be clear. The rules should be understandable. Randomness and arbitrary decisions definitely do not help. I currently also think of changes like the php_url struct that would fix a bug but is an ABI break at the same time. This is being talked down in the PR over at GitHub because of that break and the author was requested to port it to PHP 7.1. I also remember that there was once a PR with random numbers that was meant to fix a bug but also stopped because of BC concerns (cannot find it, cannot give a reference but Sara was involved). What I am saying is. A BC promise cannot be arbitrary or it means BC hell for users and frustration for people who would like to contribute to internals. Simply because you one is not allowed to touch the code unless you count to the few gurus who are allowed to do whatever they want. (This is of course exaggerated now to make a point and biased.) On 6/13/2016 4:32 PM, Joe Watkins wrote: > I think our policy has always been to consider each proposal on a > case-by-case basis. That's all I have done, and all I am suggesting oth= ers > do. >=20 > I know it's very strange to hear someone talking about "goals" ... >=20 > We can waste a bunch of time trying to define them, voting on them, and= so > on ... or, we can look at what is going on, and what has gone on, and c= ome > to sensible conclusions. >=20 Ultimately meaning that there is no BC promise whatsoever and everyone is at the mercy of the voters. This is especially striking me because one of the main arguments against many RFCs that want to deprecate something is that people will never upgrade because it makes upgrades hard for them (note, we are talking about deprecations here and BCs in much, much later versions). Introduction of random BCs is not? We definitely should make up goals, clear goals. Goals that are understandable by users. Goals that draw a vision of where we want to go. Improving the performance and engine could be on top of that, I am sure everybody will be in favor of it anyways. ;) --=20 Richard "Fleshgrinder" Fussenegger --3q878V6P5rK95F7kniObLiAgokmEFAUV8-- --IJxPeKWhaCBf20uf8uJICSRaO4trmoFWN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXXvGEAAoJEOKkKcqFPVVryEUQAKbBJmRe+/Pl23fKxiENQaAN lu288dbVFBprXlXGTZC/NVRZVKauz0dyvw6a9TkINn61povA8i97tpRuoU2Gkj6G ouKrQDw0n3n1pdBWiizYOM7mWkXW7SbxW8bwV/shmDBxNvmFqdvvX/OZKFR9rjEa sN2EuBzvY56rX8TJc11VAN9+8X4aGv5isI8XTo7y23vT0FC+mWybP/o+l8e3IaEt +jKRBncSGauykkSxMFockTcY0Y65eMdVrcrWqq1FNeB1cuV3TFrXo1+xFxjAgMHV 72SdtH/O/FcEuGuwMQ/NR+XiuIc3kSyurliCH4BhekbGxuGb9el/lgqPxdnuU2YP xDhQpWXTSiJZZAMQaLJ/r79iV+3zElMf3f3M7rskJ5riuGmmT6QGcqlH8xoNSCUG qKLr64T+Yc7LzDtJNKHK83mUFTzEGr4hhRuON21y3ODOfkFGi3EFjjue97vdvuZx wRBNtC3J+tNv/AH267O/JPaVFsl6XYT0lKitlxG6yRHAR2tYraZ7LTn8WqhRX6SK vWeOkiuCwxbddQAsAVPlqLjm6cM5Qjwht/B1RmAPfZegAeQQMdxha8guEU6MCC1x rMylwjusNr8t/IRv1hqNoJN1aSYjBTWM4l9v+239Co+Z9ePfnMhEgFhUKBiIBStv KxiD98mtyKLVJKBe2QBh =ZWmF -----END PGP SIGNATURE----- --IJxPeKWhaCBf20uf8uJICSRaO4trmoFWN--