Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.84 cause and error)
Reply-To: internals@lists.php.net
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
 <155a8c29-7858-74a6-7c45-5746d79e9a72@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>, internals@lists.php.net,
 Dmitry Stogov <dmitry@zend.com>, Rowan Collins <rowan.collins@gmail.com>
Message-ID: <18f8793d-7c03-1339-bfef-f0254b12f6c7@fleshgrinder.com>
Date: Tue, 14 Jun 2016 22:06:39 +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: <155a8c29-7858-74a6-7c45-5746d79e9a72@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="fQiaTeGIhT3c1mtmxW4ObKM0LbGCsX75J"
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: php@fleshgrinder.com (Fleshgrinder)

--fQiaTeGIhT3c1mtmxW4ObKM0LbGCsX75J
Content-Type: multipart/mixed; boundary="oq9UB15BwwnQXVS72ii0hB4FFfOuRDMkL"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Stanislav Malyshev <smalyshev@gmail.com>, internals@lists.php.net,
 Dmitry Stogov <dmitry@zend.com>, Rowan Collins <rowan.collins@gmail.com>
Message-ID: <18f8793d-7c03-1339-bfef-f0254b12f6c7@fleshgrinder.com>
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
 <155a8c29-7858-74a6-7c45-5746d79e9a72@gmail.com>
In-Reply-To: <155a8c29-7858-74a6-7c45-5746d79e9a72@gmail.com>

--oq9UB15BwwnQXVS72ii0hB4FFfOuRDMkL
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 6/14/2016 9:43 PM, Stanislav Malyshev wrote:
> Changing notice to warning is a breaking change too :) And I'm not sure=

> how rushing 8.0 helps anything if you're afraid of breaks - you get
> useful features later but also bigger breaks. Long term it doesn't
> matter anyway unless 7.1 is somehow special, which is not. Also, having=

> just two minor versions seems to be a little thin, unless there's a pla=
n
> to keep maintaining 7.x, in which case the question is - who's going to=

> do that?
>=20

On 6/12/2016 6:42 PM, Rowan Collins wrote:
> Here is where things begin to get subjective, but the following seem
> reasonable to me, and seem to match most decisions made up until now:
>
> - Notices, Warnings, etc, may change severity, but must not become
> Errors or Exceptions.
>

Quote from the initial message. There is no breakage by elevating an
E_NOTICE to an E_WARNING because the script continues to work without
anything. Yes, there might be a log entry from now on or (worse) a
custom error handler that is now going to jump in. As we all agreed
upon, not everything is avoidable and this particular RFC might even be
okay (I actually agree with all your reasoning but am still highly
afraid of the BC impact). It does not change the general topic being
discussed here.

Nobody said to release 8.0 right away but to start planning it. Also, if
there are enough changes pilled up to justify a new major than there is
nothing that speaks against only a few minor versions. The current
approach to release a major every 10 years is also weird. After all, PHP
did not mature as much as e.g. C or C++. Java 9 and 10 are also already
planned:

https://en.wikipedia.org/wiki/Java_version_history#Java_SE_9

Personally I think ignoring any BC promises is much more severe than
having another major pretty fast. The latter at least does not come as
little surprise box and clearly communicates what it is.

Many projects also have various release flavors to better cope with such
situations where developers feel blocked by the restrictions of BC.
Maybe that could be something for PHP too? Having a PHP 8.0.0-alpha.1 or
8.0.0-preview.1 that is released like our current minor releases. People
who feel adventurous may use it as is since it is stable but its API is
not and any upgrade may contain breaking changes.

The 7.x.x stable branch is continued being developed but all breaking
changes go into the 8.0.0-x.x mainline branch (an appropriate action is
taken in the 7.x.x stable branch like here with the raising from
E_NOTICE to E_WARNING).

Note that completely new features can directly go into both.

Nginx has a similar approach for instance, but so does Debian.

This "problem" is solvable and ignoring it or talking it down does not
help anyone! :)

--=20
Richard "Fleshgrinder" Fussenegger


--oq9UB15BwwnQXVS72ii0hB4FFfOuRDMkL--

--fQiaTeGIhT3c1mtmxW4ObKM0LbGCsX75J
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

iQIcBAEBCAAGBQJXYGPTAAoJEOKkKcqFPVVr4o4P/1FhQsTqKu8hIM5K8DAfeM33
U+3TWl4oQUQgs6Y65F+OFhOam6KFPk5n3DQd5mOabB/X0wEFDYq7pW4AE1tPjXce
f/Nn59X3ejmUCxBTkY27Tzoe8NRMbEFeb9A1iFeTAvTQzvcjBjiWIw+H3imZ+Z2e
H7gG4E+Ye4r5t6VXxGfO5hk5qtJxyMKUD4a+3EsyRU8j8RfxVVXpVXDwVwhGw/DL
31JooOfa4FbQE/VUZb8QZxlCGZyPa+mXvAGr55v9WWvQZxfGDQmXGdnNjWcIQN4O
dYg22+8lJDfIfBBAuHYpHPXbtoVkg1l78te823GEm+NTRgAxno5EuhsNHWxovTxC
Gx6ABQDANSCEij68aj2n468nLshpoL5ObYg86EybqDAc7D5k6TzqpLoJLUCp5zKE
HqaEZPr5/EIeZ4xaNhU6XIQ7Q85VtTYPIFrY7cW9ouvxlpqZtW9mho5GQJDxaGSH
Iv/HdY2fy6/9VVlSqzPL0aqBiPVIjGAaTV4nIh7ASCrVqWwh9+1D9XihNH/QYmiY
4OHbKSeJs+N1qfPstJ5V7uY0C5fAjQp/MGsTs3qIS2YLobzwuW1uEicPhWzGD9H7
GxB1iFzkRfCdFhRqBRU9ju0shkNH9PMmTbPmtdY7LS5i2v3+Hf32MyZ5hp8KwmnI
eJmGKRKCTFS8Nk5KB/Uy
=F3vC
-----END PGP SIGNATURE-----

--fQiaTeGIhT3c1mtmxW4ObKM0LbGCsX75J--