Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104807
MIME-Version: 1.0
References: <2a08bdcd-b98c-1572-2aae-07af61a29a3e@gmx.de> <c341c5f7-974f-536a-5075-f04773ec9605@gmx.de>
 <alpine.DEB.2.21.1903111419150.24827@singlemalt.home.derickrethans.nl>
 <34920d43-2b90-507c-c96b-8a80a192c4c9@gmx.de> <CAESVnVpvwtUtVuaKwV_GxnHAUv65g+bzb=As7itm-uFTU6XUZw@mail.gmail.com>
 <cb3289b9-5dc3-6ae8-7424-e5e71618bc99@fedoraproject.org> <CAESVnVp9qYHg_aWO3R7XGtvRpuwL_=zEiioeFppMC_2FJWWh=Q@mail.gmail.com>
 <CAOwTYAuvwEtJm8FOLQvLoNmCR37KSiB56E-fP0FURoFnh1rSRg@mail.gmail.com>
 <56361e37-1c5d-244a-7f98-362a89e383ce@php.net> <1695f069-9d69-cc8f-2155-d680dc7f77fe@telia.com>
In-Reply-To: <1695f069-9d69-cc8f-2155-d680dc7f77fe@telia.com>
Date: Tue, 19 Mar 2019 21:06:33 +0100
Message-ID: <CAOwTYAuVMtE+2ghfdhbzVWu-4vw5DLSGrLxpW=PLv2r9m75xJA@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Sebastian Bergmann <sebastian@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006176e50584780b26"
Subject: Re: [PHP-DEV] Re: PHP 7.4 Release Manager Selection
From: krakjoe@gmail.com (Joe Watkins)

--0000000000006176e50584780b26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

They sound like justifications for 5.6 support being extended.

I think there are good reasons to stick to schedule for 7.4: 8.0 is certain
to contain JIT, 7.4 is not, but should 7.4 get the JIT then it will be
experimental, and because of ABI guarantees and BC concerns will be more or
less stale in the 7.4 branch, with a focus on 8. It will not be good to
have an experimental feature being used in production for an additional
year. If 7.4 doesn't get the JIT then that's a really good reason to
upgrade to 8, which will help adoption, and extending support will harm
adoption.

The upgrade from 7.4 to 8 for tools like smarty should be relatively
painless, if any changes are needed at all they will be quick and easy. The
same for third party extensions most likely ... This isn't comparable to
5.6 to 7 where rather a lot of extension code needed to be rewritten, and
userland code may have been broken.

What is clear is that we should not be adjusting policy with extended
support for the last release in a series, if we are going to extend support
then it should be for reasons beyond "it's the final release in this
series".

Cheers
Joe

On Tue, 19 Mar 2019, 20:50 Bj=C3=B6rn Larsson, <bjorn.x.larsson@telia.com> =
wrote:

> Den 2019-03-19 kl. 17:53, skrev Sebastian Bergmann:
> > Am 19.03.2019 um 17:43 schrieb Joe Watkins:
> >> At least I'd like someone to explain in detail why we should extend
> >> support
> >> for 7.4?
> >
> > Seconded.
> >
> For us the extended support of 5.6 has been very beneficial.
> Primarily for two reasons:
> - A large legacy code base that took time to fix.
> - Adaption of third-party tools takes time. For instance latest
>    version of smarty that we use, still gives error messages for
>    PHP 7.3 (a standard plugin).
>
> I don't expect the above to change going from 7.4 to 8.0. Of
> course it depends on the 8.0 features and BC breaks.
>
> Also looking at the 7.4 content it seems quite attractive! So
> given that we don't yet know uptake of 8.0, 7.4 could have
> a long lifespan.
>
> Another point is that when looking in the control panel for
> our server that incorporates PHP, 5.6.40 is listed as outdated.
> If it had been a year ago instead (no extended support ), then
> it would have felt weird since 5.6 has executed flawlessly in
> 2018 for us.
>
> Finally, given that the extended support for 5.6 has been quite
> a success, having the same for 7.4 seems prudent at this point
> in time.
>
> r//Bj=C3=B6rn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000006176e50584780b26--