Hi all,
quite a while ago I've submitted
https://github.com/php/php-src/pull/4917, but received no feedback on
that so far, so I'm writing this mail.
The pull request is about bumping the required libcurl version for
ext/curl to 7.17.1, which has been released twelve years ago. The main
reason for the bump is to remove most of the obsolete constants which
have been scheduled for removal from libcurl for more than ten years.
The fact that we still use them, has almost bitten us not long ago[1],
so I think that PHP 8 is a good opportunity to finally remove them.
If there are no objections, I'll merge PR #4917 in a week.
[1] https://github.com/curl/curl/pull/4601
Thanks,
Christoph
Good morning Christoph,
I would even bump it to a much more recent version for 8.x or we will
have the same issue during 8.x lifetime (we may anyway but starting
with a 10+ years old version makes it much more likely).
Best,
Hi all,
quite a while ago I've submitted
https://github.com/php/php-src/pull/4917, but received no feedback on
that so far, so I'm writing this mail.The pull request is about bumping the required libcurl version for
ext/curl to 7.17.1, which has been released twelve years ago. The main
reason for the bump is to remove most of the obsolete constants which
have been scheduled for removal from libcurl for more than ten years.
The fact that we still use them, has almost bitten us not long ago[1],
so I think that PHP 8 is a good opportunity to finally remove them.If there are no objections, I'll merge PR #4917 in a week.
[1] https://github.com/curl/curl/pull/4601
Thanks,
Christoph--
--
Pierre
@pierrejoye | http://www.libgd.org
Why not the most recent and stable version?
I'm thinking modern version has many bugs fixed and many vulnerabilities
fixed, even with improvements that make things more faster and lighter...
Just My thoughts.
Good morning Christoph,
I would even bump it to a much more recent version for 8.x or we will
have the same issue during 8.x lifetime (we may anyway but starting
with a 10+ years old version makes it much more likely).Best,
On Wed, Jan 8, 2020 at 9:50 PM Christoph M. Becker cmbecker69@gmx.de
wrote:Hi all,
quite a while ago I've submitted
https://github.com/php/php-src/pull/4917, but received no feedback on
that so far, so I'm writing this mail.The pull request is about bumping the required libcurl version for
ext/curl to 7.17.1, which has been released twelve years ago. The main
reason for the bump is to remove most of the obsolete constants which
have been scheduled for removal from libcurl for more than ten years.
The fact that we still use them, has almost bitten us not long ago[1],
so I think that PHP 8 is a good opportunity to finally remove them.If there are no objections, I'll merge PR #4917 in a week.
[1] https://github.com/curl/curl/pull/4601
Thanks,
Christoph--
--
Pierre@pierrejoye | http://www.libgd.org
Why not the most recent and stable version?
I'm thinking modern version has many bugs fixed and many vulnerabilities
fixed, even with improvements that make things more faster and lighter...
Using the most recent version would make it more difficult for people
on supported but not cutting edge operating systems to build from
source. IMO, it should be buildable on all major Linux operating
systems in regular support using their native packaging system. The
oldest supported OS and version I can even conceivably care about is
RHEL/CentOS 6 (which is in extended security mode), which appears to
use curl 7.19; after that RHEL/CentOS 7 uses curl 7.29.
In other words, I recommend against requiring the latest curl
version and but do recommend bumping the minimum up to at least v7.19.
Unless we really need something from newer versions (which it doesn't
look like we do), anything newer than 7.29 would just cause friction
for people building from source.
On Sun, 12 Jan 2020 at 23:33, Levi Morrison via internals <
internals@lists.php.net> wrote:
On Sat, Jan 11, 2020 at 4:57 AM Olumide Samson oludonsexy@gmail.com
wrote:Why not the most recent and stable version?
I'm thinking modern version has many bugs fixed and many vulnerabilities
fixed, even with improvements that make things more faster and lighter...Using the most recent version would make it more difficult for people
on supported but not cutting edge operating systems to build from
source. IMO, it should be buildable on all major Linux operating
systems in regular support using their native packaging system. The
oldest supported OS and version I can even conceivably care about is
RHEL/CentOS 6 (which is in extended security mode), which appears to
use curl 7.19; after that RHEL/CentOS 7 uses curl 7.29.In other words, I recommend against requiring the latest curl
version and but do recommend bumping the minimum up to at least v7.19.
Unless we really need something from newer versions (which it doesn't
look like we do), anything newer than 7.29 would just cause friction
for people building from source.--
As this is targeting PHP 8 I would say 7.29 would be better IMHO as
RHEL/CentOS 6 EOL is November 30, 2020 [1] [2] which means it would be
EOL just after PHP 8 is released (if PHP 8 is release on the yearly
schedule).
My two cents
Best regards
George P. Banyard
[1] https://endoflife.software/operating-systems/linux/centos
[2] https://access.redhat.com/discussions/2399461
On Sun, 12 Jan 2020 at 23:33, Levi Morrison via internals <
internals@lists.php.net> wrote:In other words, I recommend against requiring the latest curl
version and but do recommend bumping the minimum up to at least v7.19.
Unless we really need something from newer versions (which it doesn't
look like we do), anything newer than 7.29 would just cause friction
for people building from source.As this is targeting PHP 8 I would say 7.29 would be better IMHO as
RHEL/CentOS 6 EOL is November 30, 2020 [1] [2] which means it would be
EOL just after PHP 8 is released (if PHP 8 is release on the yearly
schedule).[1] https://endoflife.software/operating-systems/linux/centos
[2] https://access.redhat.com/discussions/2399461
I agree that it makes sense to bump to >= 7.29.0 for PHP 8.0.0, and have
updated the PR accordingly.
Thanks,
Christoph