I've been thinking about this since we added the fourth alpha and
pushed the schedule down, but thinking about the EOL of 7.0 on Dec
3rd, I'm wondering if it'd be worth skipping RC6 in order to GA 7.3.0
on Nov 22 (previously scheduled date) slightly ahead of the Dec 3
deadline. Obviously doing so would be contingent on the build looking
stable as of RC5, and primarily the call of cmb and stas, but I wanted
to get others' thoughts.
-Sara
I've been thinking about this since we added the fourth alpha and
pushed the schedule down, but thinking about the EOL of 7.0 on Dec
3rd, I'm wondering if it'd be worth skipping RC6 in order to GA 7.3.0
on Nov 22 (previously scheduled date) slightly ahead of the Dec 3
deadline. Obviously doing so would be contingent on the build looking
stable as of RC5, and primarily the call of cmb and stas, but I wanted
to get others' thoughts.
I've thought about this as well, but given that some widely used PECL
extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
mailparse[2] and uopz[3]) (Remi may have more to say on this), it might
be better to still have two additional RCs (RC4 has been tagged
yesterday). Furthermore, timelib has only recently been upgraded to
2018.01RC1[4], and I think it may need some time to be stable.
[1] https://bugs.php.net/bug.php?id=76522
[2] https://bugs.php.net/bug.php?id=77045
[3] https://github.com/krakjoe/uopz/issues/79
[4]
http://git.php.net/?p=php-src.git;a=commit;h=220a2239a6c2cc76621d5b7d0584ab3b2797958e
--
Christoph M. Becker
I've thought about this as well, but given that some widely used PECL
extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
mailparse[2] and uopz[3]) (Remi may have more to say on this), it might
be better to still have two additional RCs (RC4 has been tagged
yesterday). Furthermore, timelib has only recently been upgraded to
2018.01RC1[4], and I think it may need some time to be stable.
That puts done to that topic then. Full RC cycle it is.
I've been getting use out of ext/yaml, I'll take a look at addressing
its 7.3 compat.
-Sara
I've been thinking about this since we added the fourth alpha and
pushed the schedule down, but thinking about the EOL of 7.0 on Dec
3rd, I'm wondering if it'd be worth skipping RC6 in order to GA 7.3.0
on Nov 22 (previously scheduled date) slightly ahead of the Dec 3
deadline. Obviously doing so would be contingent on the build looking
stable as of RC5, and primarily the call of cmb and stas, but I wanted
to get others' thoughts.I've thought about this as well, but given that some widely used PECL
extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
mailparse[2] and uopz[3]) (Remi may have more to say on this), it might
be better to still have two additional RCs (RC4 has been tagged
yesterday). Furthermore, timelib has only recently been upgraded to
2018.01RC1[4], and I think it may need some time to be stable.[1] https://bugs.php.net/bug.php?id=76522
[2] https://bugs.php.net/bug.php?id=77045
[3] https://github.com/krakjoe/uopz/issues/79
[4] http://git.php.net/?p=php-src.git;a=commit;h=220a2239a6c2cc76621d5b7d0584ab3b2797958e
timelib should be considered stable, the last RC was just a data update.
The commit ([4]) however, is unrelated to timelib?
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug
timelib should be considered stable, the last RC was just a data update.
Great! There may have to be some adjustments made to other extensions,
see https://github.com/hnw/php-timecop/issues/42.
The commit ([4]) however, is unrelated to timelib?
Sorry, this should have been
http://git.php.net/?p=php-src.git;a=commit;h=9c608bd13f780f822cd12c858f6ea271b9c7a3fb.
--
Christoph M. Becker
"Christoph M. Becker" in php.internals (Wed, 24 Oct 2018 19:37:57 +0200):
I've thought about this as well, but given that some widely used PECL
extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
mailparse[2] and uopz[3]) (Remi may have more to say on this), it might
be better to still have two additional RCs (RC4 has been tagged
yesterday).
Additional extensions that are not ready for PHP 7.2 yet:
- wincache
- pthreads https://github.com/krakjoe/pthreads/issues/889#issuecomment-412330976
- request https://github.com/pmjones/ext-request/pull/14
- msgpack https://github.com/msgpack/msgpack-php/pull/124
--
Jan
Jan Ehrhardt in php.internals (Thu, 25 Oct 2018 06:02:31 +0200):
Additional extensions that are not ready for PHP 7.2 yet:
7.3
Le 24/10/2018 à 19:37, Christoph M. Becker a écrit :
I've thought about this as well, but given that some widely used PECL
extensions are not ready for PHP 7.3 yet (for instance, yaml[1],
mailparse[2] and uopz[3]) (Remi may have more to say on this)
I track extensions' status on
https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3
91 are OK
31 are WIP (fixed upstream or PR waiting review)
12 are KO
ev and zmq could be other used ones
(for zmq PR open to fix the build, but still segfault in test suite)
Remi
Remi Collet in php.internals (Thu, 25 Oct 2018 07:32:00 +0200):
https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3
You can move v8js to work-in-progress. There is a 7.2+ branch:
https://github.com/phpv8/v8js/issues/374#issuecomment-421262169
The Appveyor builds pass all applicable tests on Windows:
https://ci.appveyor.com/project/Jan-E/v8js-rx24a/build/1.0.58
Jan
Remi Collet in php.internals (Thu, 25 Oct 2018 07:32:00 +0200):
https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3
You can move v8js to work-in-progress. There is a 7.2+ branch:
https://github.com/phpv8/v8js/issues/374#issuecomment-421262169The Appveyor builds pass all applicable tests on Windows:
https://ci.appveyor.com/project/Jan-E/v8js-rx24a/build/1.0.58Jan
--
I dont remember the status here, but , those extensions are not built-in
right ?
It seems to me like we are waiting for the world to upgrade its code, to
release our next release.
Have we always done that before ?
What I remember, is that we wait for bundled extensions (those are the ones
shipped with the PHP source code) to be compatible, but not for the all
world's extension.
Just asking :-)
Julien.Pauli
Remi Collet in php.internals (Thu, 25 Oct 2018 07:32:00 +0200):
https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3
You can move v8js to work-in-progress. There is a 7.2+ branch:
https://github.com/phpv8/v8js/issues/374#issuecomment-421262169The Appveyor builds pass all applicable tests on Windows:
https://ci.appveyor.com/project/Jan-E/v8js-rx24a/build/1.0.58I dont remember the status here, but , those extensions are not built-in
right ?
Yes.
It seems to me like we are waiting for the world to upgrade its code, to
release our next release.
Have we always done that before ?What I remember, is that we wait for bundled extensions (those are the ones
shipped with the PHP source code) to be compatible, but not for the all
world's extension.
Well, it's not that we wait until all external extensions are
compatible, but we rather give them two more weeks to catch up – or,
even rather, we don't ship GA earlier than scheduled as of 2018-07-11.
--
Christoph M. Becker