Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ncsu.edu from 209.85.161.182 cause and error)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <a969a6a3-0340-b038-ee8a-ec7d64685868@librelamp.com>
Date: Sat, 23 Jun 2018 19:15:32 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <0E4B6C07-FF63-4221-867E-4D7EAE9770E7@ncsu.edu>
References: <CAF+90c8S3UK3xakJQ4eD1mCMvBAdms2_d5aDd0oOZHfi67Mn9Q@mail.gmail.com> <CAESVnVqKqLDcbrTwzSD2qms32kF3FROa6XGXp9UEgp2MLjDvPw@mail.gmail.com> <DM5PR0201MB35423C070BADA25899A12E1EAC740@DM5PR0201MB3542.namprd02.prod.outlook.com> <a969a6a3-0340-b038-ee8a-ec7d64685868@librelamp.com>
To: Alice Wonder <alice@librelamp.com>
Subject: Re: [PHP-DEV] PHP 8 next?
From: mdwheele@ncsu.edu (Dustin Wheeler)

Hello,=20

> On Jun 23, 2018, at 6:38 PM, Alice Wonder <alice@librelamp.com> wrote:
>=20
>> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
>>=20
>> This is slightly earlier than I intended to bring it up but I do too thin=
k that the next version beyond 7.3 should be 8.
>=20
> I disagree.
>=20
> I'm mostly a user, not a PHP developer.
>=20
> RHEL 7.5, the latest version of RHEL, still ships 5.4.
>=20

RHEL has official software collections for PHP 7.0 and 7.1. Remi has an SCL f=
or 7.2. We run 7.2 in production and 5.6 is gone in December. 5.4.16 in RHEL=
 was... a mistake. There is nothing =E2=80=9Cun-enterprise=E2=80=9D about th=
e SCLs and they work very well.=20

RHEL 8 is coming soon and is based on Fedora 28. It will likely ship 7.2, I i=
magine.=20

> Other LTS distributions also probably ship 5.x.
>=20

Ubuntu 16.04 LTS shipped with PHP 7.0. Ubuntu 18.04 LTS ships with PHP 7.2. P=
HP 5.* was a great line but it has been time to move for a while. It=E2=80=99=
s getting harder to come up with reasoning to stay. I haven=E2=80=99t come a=
cross a codebase that didn=E2=80=99t run on 7+ and this includes a 16 year o=
ld codebase that started on PHP 4. It=E2=80=99s an anecdote, but proof that a=
nything is possible.=20

> So a major version bump now would mean three major versions of PHP that we=
b applications intended to "just work" on enterprise *nix would have to supp=
ort.
>=20

For sure, this is the distribution=E2=80=99s choice, not the maintainers her=
e.=20

> If there was a major design flaw in PHP that can only truly be fixed by an=
 incompatible version bump past 7 then do it but otherwise, I think it would=
 be better to wait until the most recent versions of enterprise distribution=
s have moved to php 7.
>=20
> I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
>=20
> The issue is some customers of enterprise linux specifically don't want fr=
ankenstein systems and want to use vendor supported packages only, and I can=
 see their point of view because they pay a lot of money for that support.
>=20
> That being said, I try to get everyone running old PHP up to 7.1 or 7.2 ev=
en if it means frankenstein systems. But some think the benefit of enterpris=
e vendor support outweighs the improvements in PHP.

I have Puppet to manage LAMP using httpd24 and php72 on RHEL if you=E2=80=99=
re interested. Once it is in config management, it=E2=80=99s not =E2=80=9CFra=
nkenstein=E2=80=9D anymore. And if folks complain about =E2=80=9CFrankenstei=
n=E2=80=9D systems when their definition of such is using software collectio=
ns, I would argue their not getting value out of the product provided by Red=
Hat, as SCL versions of PHP are provided by the vendor! Use them!


-Dustin=