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
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
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
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
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
Fine print: Oracle 19 is a long-term release. Using Oracle Client 19c
libraries lets OCI8 connect to Oracle DB 11.2 or later.
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.
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
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
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
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.
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
Hi Sara,
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
337d2af6ca50a52864034446d863331cbc61885eHi 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
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
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