Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Preparing for PHP 8.0.0 GA »

Preparing for PHP 8.0.0 GA

php.internals

Sara Golemon

5 years ago
I've just cut the release branch for PHP-8.0.0 final which will be released in one week on 26 Nov. Minor bug fixes can continue to be merged via the PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what 8.0.0RC5 contained unless serious issues are encountered. If you feel you have a fix which should be included in the 8.0.0 final release, please let Gabriel and I know which commit you would like cherry-picked onto that release spur. Please also help me out by reviewing the NEWS, UPGRADING, and UPGRADING.INTERNALS files: https://github.com/php/php-src/blob/PHP-8.0.0/ Lastly, there are likely still gaps in the documentation of new features, so please take a moment away from code to make the manual better. -Sara

Côme Chilliet

5 years ago
Le Thu, 19 Nov 2020 08:50:04 -0600, Sara Golemon <pollita@php.net> a écrit :
> Lastly, there are likely still gaps in the documentation of new features, > so please take a moment away from code to make the manual better.
With the huge changes on parameter names in PHP-8, is there any easy automated process to fix documentation pages to match stubs? Côme

Christoph Becker

5 years ago
On 19.11.2020 at 17:52, Côme Chilliet wrote:
> Le Thu, 19 Nov 2020 08:50:04 -0600, > Sara Golemon <pollita@php.net> a écrit : > >> Lastly, there are likely still gaps in the documentation of new features, >> so please take a moment away from code to make the manual better. > > With the huge changes on parameter names in PHP-8, is there any easy automated > process to fix documentation pages to match stubs?
Máté provided an enhancement to gen_stub.php[1], and we're currently going through all internal functions[2]. Help with reviewing the PRs is highly appreciated; we have to make sure that the docs are still valid for PHP 7.0+. [1] <https://github.com/php/php-src/pull/6367> [2] <https://github.com/php/doc-en/pulls?q=is%3Apr+label%3Amethodsynopses+> Christoph

Christopher Jones

5 years ago
On 20/11/20 1:50 am, Sara Golemon wrote:
> I've just cut the release branch for PHP-8.0.0 final which will be released > in one week on 26 Nov. Minor bug fixes can continue to be merged via the > PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what > 8.0.0RC5 contained unless serious issues are encountered.
What is the status of Windows builds? In particular who can I work with to get the build to use updated Oracle client libraries for the OCI8 extension in the PHP bundle and the upcoming OCI8 3.0 release on PECL?  I.e. drop building with 11g and add 19c? Fine print: Oracle 19 is a long-term release.  Using Oracle Client 19c libraries lets OCI8 connect to Oracle DB 11.2 or later. Chris
-- https://twitter.com/ghrd

Christoph Becker

5 years ago
On 24.11.2020 at 03:40, Christopher Jones wrote:
> On 20/11/20 1:50 am, Sara Golemon wrote: > >> I've just cut the release branch for PHP-8.0.0 final which will be >> released >> in one week on 26 Nov.  Minor bug fixes can continue to be merged via the >> PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what >> 8.0.0RC5 contained unless serious issues are encountered. > > What is the status of Windows builds? > > In particular who can I work with to get the build to use updated Oracle > client libraries for the OCI8 extension in the PHP bundle and the > upcoming OCI8 3.0 release on PECL?  I.e. drop building with 11g and add > 19c?
Well, I can update the OCI8 SDK on the build machine (assuming there are no licensing issues), and roll a snapshot build (assuming that there are no incompatibilities), but I wouldn't be able to run any tests. Christoph

Dmitry Stogov

5 years ago
Hi, I finally fixed all the known JIT related issues and made the PHP-8.0 build "green". https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088&view=results Please, cherry-pick the following 5 commits into PHP-8.0.0. c8df28d276c25c6f5ad0f1ab2727804b32be8cfe c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5 586ccfdfd5179336dcf3719577b8258e55e7d76e 337d2af6ca50a52864034446d863331cbc61885e Thanks. Dmitry. On Thu, Nov 19, 2020 at 5:50 PM Sara Golemon <pollita@php.net> wrote:

Sara Golemon

5 years ago
On Tue, Nov 24, 2020 at 12:35 AM Dmitry Stogov <dmitrystogov@gmail.com> wrote:
> I finally fixed all the known JIT related issues and made the PHP-8.0 > build "green". > > > https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088&view=results > > Please, cherry-pick the following 5 commits into PHP-8.0.0. > > c8df28d276c25c6f5ad0f1ab2727804b32be8cfe > c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4 > 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5 > 586ccfdfd5179336dcf3719577b8258e55e7d76e > 337d2af6ca50a52864034446d863331cbc61885e > >> >>
Hi Dmitry, that's great news. Given that the JIT is enabled by default, I'm tempted to add another RC and delay the release. As the person who did this work, can you reassure my worries and tell me that's not needed? The good news is that none of these commits look particularly complex. -Sara c8df28d276 Fixed 32-bit JIT c0d1dbcb43 Fixed incorrect TRACE_FRAME_MASK_NESTED flag setting 4cf3da7383 Keep value of register before possible side exit 586ccfdfd5 Fixed use-after-free in PHPUnit tests 337d2af6ca zend_jit_trace_stack_frame.stack can't be NULL

Sara Golemon

5 years ago
On Tue, Nov 24, 2020 at 8:55 AM Sara Golemon <pollita@php.net> wrote:
> Given that the JIT is enabled by default, I'm tempted to add another RC > and delay the release. > >
As Niki just helpfully pointed out; My understanding of the JIT's setting on 8.0 is wrong. It's "on", but with a 0-sized buffer, so it's effectively disabled. #1 I feel so much more secure in this whole release than I did five minutes ago. No offence. :) #2 We can afford to be a little lax on pulling in those cherry-picks. So now the question is what is the impact of (not) pulling them into the release at the literal last minute. On the one hand, by the book, this is too late for a non-security fix. On the other hand, this is .0, and it's impacting a not-enabled-by-default path, so we can be more generous. Right now I'm inclined to pull them in, but I'll wait a few hours for anyone who wishes to object. (It's still only 9am here :p ) -Sara

Dmitry Stogov

5 years ago
On Tue, Nov 24, 2020 at 6:14 PM Sara Golemon <pollita@php.net> wrote:
> On Tue, Nov 24, 2020 at 8:55 AM Sara Golemon <pollita@php.net> wrote: > >> Given that the JIT is enabled by default, I'm tempted to add another RC >> and delay the release. >> >> > As Niki just helpfully pointed out; My understanding of the JIT's setting > on 8.0 is wrong. It's "on", but with a 0-sized buffer, so it's effectively > disabled. > #1 I feel so much more secure in this whole release than I did five > minutes ago. No offence. :) > #2 We can afford to be a little lax on pulling in those cherry-picks. > > So now the question is what is the impact of (not) pulling them into the > release at the literal last minute. > On the one hand, by the book, this is too late for a non-security fix. On > the other hand, this is .0, and it's impacting a not-enabled-by-default > path, so we can be more generous. > >
I think many people are going to try JIT in PHP-8.0.0. The last commits fix incorrect behavior of JIT generated code on some edge cases. e.g. wrong reference-counting and following use-after-free on PHPUnit tests. Releasing PHP-8.0.0 with already fixed bugs would cause false reports. On the other hand the risk of these commits is minimal. Thanks. Dmitry.

Dmitry Stogov

5 years ago
Hi Sara, On Tue, Nov 24, 2020 at 5:56 PM Sara Golemon <pollita@php.net> wrote:
> On Tue, Nov 24, 2020 at 12:35 AM Dmitry Stogov <dmitrystogov@gmail.com> > wrote: > >> I finally fixed all the known JIT related issues and made the PHP-8.0 >> build "green". >> >> >> https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13088&view=results >> >> Please, cherry-pick the following 5 commits into PHP-8.0.0. >> >> c8df28d276c25c6f5ad0f1ab2727804b32be8cfe >> c0d1dbcb432f65d09f1c88cc368aa89eb5f067f4 >> 4cf3da73839b1ef3ab1fc8f74aee3a00237ad6b5 >> 586ccfdfd5179336dcf3719577b8258e55e7d76e >> 337d2af6ca50a52864034446d863331cbc61885e >> >>> >>> > Hi Dmitry, that's great news. > > Given that the JIT is enabled by default, I'm tempted to add another RC > and delay the release. > As the person who did this work, can you reassure my worries and tell me > that's not needed? > The good news is that none of these commits look particularly complex. >
I think, new RC is not necessary. These commits only affect JIT. They fix the recently found problems and don't show any degradation. Thanks. Dmitry.

Sara Golemon

5 years ago
On Tue, Nov 24, 2020 at 10:27 AM Dmitry Stogov <dmitrystogov@gmail.com> wrote:
> I think, new RC is not necessary. > These commits only affect JIT. They fix the recently found problems and
don't show any degradation.
>
Good enough for me. I'll pull 'em up and cut in the next couple hours. -Sara