Bump required libcurl version to 7.29.0

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!

[cmb69]

libcurl 7.17.1 has been released 12 years ago, so it doesn't seem
reasonable to still cater to older versions. The main reason for this
version bump is to cater to a mass renaming of CURLE_* constants in
7.17.0 (and a single further renaming in 7.17.1), whereby many of the
old constants have been marked obsolete, and according to curl.h have
been scheduled for removal in 2009 already.

So we remove all respective PHP CURLE_* constants, and add not yet
available replacements, except for those constants which have been
marked as being obsolete (CURLE_OBSOLETE*), since these error codes
are not supposed to be returned ever.

Renamed constants:

• CURLE_FTP_ACCESS_DENIED → CURLE_REMOTE_ACCESS_DENIED
• CURLE_FTP_BAD_DOWNLOAD_RESUME → CURLE_BAD_DOWNLOAD_RESUME
• CURLE_FTP_COULDNT_SET_BINARY → CURLE_FTP_COULDNT_SET_TYPE
• CURLE_FTP_COULDNT_STOR_FILE → CURLE_UPLOAD_FAILED
• CURLE_FTP_PARTIAL_FILE → CURLE_PARTIAL_FILE
• CURLE_FTP_QUOTE_ERROR → CURLE_QUOTE_ERROR
• CURLE_HTTP_NOT_FOUND → CURLE_HTTP_RETURNED_ERROR
• CURLE_HTTP_PORT_FAILED → CURLE_INTERFACE_FAILED
• CURLE_HTTP_RANGE_ERROR → CURLE_RANGE_ERROR
• CURLE_OPERATION_TIMEOUTED → CURLE_OPERATION_TIMEDOUT
• CURLE_SSL_PEER_CERTIFICATE → CURLE_PEER_FAILED_VERIFICATION
• CURLE_URL_MALFORMAT_USER → CURLE_NOT_BUILT_IN
• CURLE_FTP_SSL_FAILED → CURLE_USE_SSL_FAILED

Removed constants:

• CURLE_BAD_CALLING_ORDER
• CURLE_BAD_PASSWORD_ENTERED
• CURLE_FTP_CANT_RECONNECT
• CURLE_FTP_COULDNT_GET_SIZE
• CURLE_FTP_COULDNT_SET_ASCII
• CURLE_FTP_USER_PASSWORD_INCORRECT
• CURLE_FTP_WEIRD_USER_REPLY
• CURLE_FTP_WRITE_ERROR
• CURLE_LIBRARY_NOT_FOUND
• CURLE_OBSOLETE
• CURLE_SHARE_IN_USE
• CURLE_MALFORMAT_USER

---

While I find it a bit unfortunate that we can't deprecate the removed/renamed constants, I think this removal/renaming has to be done for PHP 8.0, since otherwise we're at risk that we can't build against future libcurl versions anymore.

Even with this patch, building with CURL_NO_OLDIES defined still doesn't succeed, but I'm planning to cater to the seven other obsolete constant in a separate PR, because these appear to be more controversial, mainly since they have only been obsoleted in later versions.

[nikic]

I've opened #5072 to add support for deprecation constant. I think our course of action here should be to deprecate the old names and internally define their values to the new constants. That way we can avoid issues if the constants are removed, but can handle the deprecation/removal on our own schedule (as you mention, there are a number that are more recent).

[cmb69]

Thanks! That sounds sensible. Will update the PR ASAP.

[remicollet]

Even RHEL / CentOS 6 have 7.19.7, and is probably the older maintained distribution (and will be EOL in a few months), and BTW most of lib. are already outdated and recent PHP 7.4 can not be build there without some big effort.

RHEL / CentOS 7 (5 years old, will be maintained until 2024) have 7.29.0

So fine for me to bump mininal required version to anything less than 7.29

[Girgias]

As said on the mailing list, I would rather see a "major" bump in the required version and bump it directly to 7.29.0 than go for an older release.

But just my opinion :)

[cmb69]

I have now undone the removal of the constants (which can still be done later; should wait for PR #5072), but bumped the requirements to libcurl >= 7.29.0, which appears to have consensus.

[nikic]

LGTM modulo one test.

[cmb69]

Applied as 7426e3b. Thanks!