What's changing in curl 8

From: Dan Fandrich via curl-users <curl-users_at_lists.haxx.se>
Date: Sat, 22 Oct 2022 20:22:26 -0700

With the curl version 8 release scheduled for next March, we need to get
some traction on what changes are going into that release. The consensus
so far seems to be that 8.0.0 isn't going to be really that different
from a regular release, with no breaking changes going in, but we should
consider using this psychologically-significant version bump to perform
a few bigger cleanups that we might not ordinarily do.

While curl tries in general to preserve backward compatibility (and
avoid major library number bumps, which are intrusive), it doesn't do
this perfectly, even today. For example, several error codes have been
reassigned over the years. Technically, that should have resulted in an
SONAME bump but that wasn't done, probably because the old codes haven't
been used in so long that it wasn't worth considering preserving
backward compatibility that far back. I'm suggesting that now's the
time to consider making some changes along that same level. There are a
bunch of APIs that people shouldn't be using any more, that still bring
us headaches (such as a recent PR to improve the obsolete curl_formadd
API) so this can reduce our support burden.

Since people have been conditioned to expect a version number bump to
mean some breaking changes, we could slip in a few fixes that we might
have ordinarily held back on without surprising anyone. Here are a few
examples, starting with the entries in DEPRECATE.md:

1. Requiring support of a 64 bit long type. We're probably going to do
this regardless, but waiting until 8.0.0 might make 32-bit only folks a
bit less surprised. Actually, it looks like the plan is to do this in
8.0.0 already, so yay!

2. Removing NSS support. But, this has already been postponed past the
8.0.0 release so we shouldn't really bring the date up again.
Otherwise, it would have been another good psychological release to
implement it.

3. There used to be a "on the next SONAME bump" section in the TODO file
(sadly removed in fc9dd2d1) that could become candidates for "soft"
removal in this release. For example, obsolete & outdated APIs
(curl_getenv, curl_mprintf, curl_strequal, curl_strnequal,
curl_multi_socket, curl_multi_socket_all, curl_httppost,
CURLOPT_FAILONERROR) could have their prototypes hidden behind a special
macro so they're normally invisible from source. Ideally, applications
that failed to compile with 8.0.0 would be rewritten to use the approved
API replacements, but in a bid for a level of backward compatibility,
defining CURL_ENABLE_OBSOLETE_APIS would fix compilation (for the
moment, anyway).

4. More APIs that aren't in DEPRECATE.md file. The curl_form* functions
come to mind, along with options like CURLSSLBACKEND_POLARSSL,
CURL_VERSION_KERBEROS4, CURLINFO_TLS_SESSION. "grep -Rli deprecated
docs/" shows plenty more.

5. Everything that currently removed by defining CURL_NO_OLDIES. They
would still be available by defining CURL_ENABLE_OBSOLETE_APIS (as
above).

6. The old protocol list API in deference to CURLOPT_PROTOCOLS_STR. This
might be a bit early since the new way will only have been available to
users for two releases before being removed, so the set of libcurl
versions for which a given application would work would be too small
upon release of 8.0.0 (i.e. an application would only compile against
8.0.0 and the two previous versions).

7. The progress meter in the library. But, there's probably no clean way
of causing an application compile failure for applications that rely on
this. Maybe make --disable-progress-meter the default in configure, but
doing so could be considered by some as technically an ABI break.

8. Adding a --disable-obsolete-apis configure option that removes the
code handling everything above from the library binary. Similarly to
above, making that the default could be considered as technically an ABI
break, but when used, it makes the library smaller (and therefore
marginally faster).

9. Allow use of C99 features in the source code.

10. Somehow handle the deprecated options --egd-file & --random-file.
Causing an error on use seems too breaky, so maybe just output an error
message if they're ever used (either with or without -v).

Additionally, everything marked "deprecated" in the documentation should
be added to DEPRECATE.md (maybe in a new section), whether or not we
have long-term plans to actually delete them from the code or not.
Users probably expect all deprecated APIs to be listed in a file called
DEPRECATE.md.

Crucially, none of the above actually cause an ABI break (with a
possible exception of #7 & #8) so binary compatibility is maintained.
And source compatibility is still maintained by flipping a switch. We
could also make 8.0.0 a special out-of-band release that's made a week
after 7.87.0 that only contains these API changes. That effectively
allows applications one extra curl release cycle to fix themselves to no
longer require CURL_ENABLE_OBSOLETE_APIS (by skipping 8.0.0 and waiting
for 8.1.0).

These seem like good ways of pushing people to use better-supported
APIs, while causing only minor headaches to users who don't want to do
so (mostly just setting CPPFLAGS=-DCURL_ENABLE_OBSOLETE_APIS if you
don't want to touch your code). If we wanted to get fancy, we could even
force CURL_ENABLE_OBSOLETE_APIS to take a value indicating which old
APIs users are ignoring, e.g. -DCURL_ENABLE_OBSOLETE_APIS=8) so we can
do this song-and-dance again for 9.0.0.

What else would you add to the list?

Dan

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-10-23