Hello,
I realize that this may be a little late given that PHP 7.2 initially released
roughly 2 years ago, but I came across an issue yesterday regarding the minimum
required version of the ICU library. The user's hosting provider was using
PHP 7.2.1, but it was linked with an ICU version of 4.2.1 (over 10 years old!).
According to the https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
RFC, the INTL_IDNA_VARIANT_2003 constant was deprecated in PHP 7.2. However, this
RFC did not increase the minimum required version of ICU, which is currently
4.0 according to https://www.php.net/manual/en/intl.requirements.php. This
leaves an opening where PHP 7.2 can be built with an ICU version less than 4.6,
but the user cannot avoid the deprecation notice because the replacement,
INTL_IDNA_VARIANT_UTS46, wasn't added until ICU 4.6.
Is there any way to increase the minimum required ICU version in PHP 7.2 and 7.3 to
at least 4.6, which would ensure that the upgrade path is actually available to users
trying to avoid the deprecation notice?
Hi!
I realize that this may be a little late given that PHP 7.2 initially released
roughly 2 years ago, but I came across an issue yesterday regarding the minimum
required version of the ICU library. The user's hosting provider was using
PHP 7.2.1, but it was linked with an ICU version of 4.2.1 (over 10 years old!).According to the https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
RFC, the INTL_IDNA_VARIANT_2003 constant was deprecated in PHP 7.2. However, this
RFC did not increase the minimum required version of ICU, which is currently
4.0 according to https://www.php.net/manual/en/intl.requirements.php. This
leaves an opening where PHP 7.2 can be built with an ICU version less than 4.6,
but the user cannot avoid the deprecation notice because the replacement,
INTL_IDNA_VARIANT_UTS46, wasn't added until ICU 4.6.Is there any way to increase the minimum required ICU version in PHP 7.2 and 7.3 to
at least 4.6, which would ensure that the upgrade path is actually available to users
trying to avoid the deprecation notice?
We usually do not raise any dependency requirements for stable release
branches, to avoid potential BC breaks. And after all, most of ext/intl
is supposed to work flawlessly with such ancient ICU versions, and to be
able to get rid of this deprecation notice, building with a newer ICU
version is already possible (and, in my opinion, recommendable anyway).
Thanks,
Christoph
On Thu, Aug 22, 2019 at 2:28 AM Christoph M. Becker cmbecker69@gmx.de
wrote:
Is there any way to increase the minimum required ICU version in PHP 7.2
and 7.3 to
at least 4.6, which would ensure that the upgrade path is actually
available to users
trying to avoid the deprecation notice?We usually do not raise any dependency requirements for stable release
branches, to avoid potential BC breaks. And after all, most of ext/intl
is supposed to work flawlessly with such ancient ICU versions, and to be
able to get rid of this deprecation notice, building with a newer ICU
version is already possible (and, in my opinion, recommendable anyway).Agreed on not raising the library dependency requirement in branch, but
perhaps we can smooth the transition a little by only raising the
deprecation notice if the environment actually allows using the
non-deprecated behavior. This would have the opposite impact on the active
branch of raising the dependency while still providing the facility of a
deprecation notice to builds that aren't based on ancient ICUs.
Or perhaps tailor the deprecation warning a little? (Nevermind, I just
wrote it out and it gets ugly)
Or perhaps just stick with status quo and add a note to the manual. :D
-Sara
On Thu, Aug 22, 2019 at 2:28 AM Christoph M. Becker cmbecker69@gmx.de
wrote:Is there any way to increase the minimum required ICU version in PHP 7.2
and 7.3 to
at least 4.6, which would ensure that the upgrade path is actually
available to users
trying to avoid the deprecation notice?We usually do not raise any dependency requirements for stable release
branches, to avoid potential BC breaks. And after all, most of ext/intl
is supposed to work flawlessly with such ancient ICU versions, and to be
able to get rid of this deprecation notice, building with a newer ICU
version is already possible (and, in my opinion, recommendable anyway).Agreed on not raising the library dependency requirement in branch, but
perhaps we can smooth the transition a little by only raising the
deprecation notice if the environment actually allows using the
non-deprecated behavior. This would have the opposite impact on the active
branch of raising the dependency while still providing the facility of a
deprecation notice to builds that aren't based on ancient ICUs.
That. In my opinion, even those who use ancient ICU should be made
aware of the deprecation, to avoid issues when they finally switch to a
later PHP version with a newer ICU.
Or perhaps tailor the deprecation warning a little? (Nevermind, I just
wrote it out and it gets ugly)Or perhaps just stick with status quo and add a note to the manual. :D
That might be best.
--
Christoph M. Becker