Re: What's changing in curl 8

From: Timothe Litt <litt_at_acm.org>
Date: Sun, 23 Oct 2022 06:21:01 -0400

These are all good points.  But if the code is left in the sources, it
probably doesn't reduce the support burden.  Someone will turn on the
obsolete features and expect them to work.

It will help with code bloat - which is a good thing.  But you may end
up doing testing with the feature both on and off.

So this probably only pays off if deprecation really will lead to
removing the code.  Many attempts don't.  There's one OS that I use that
maintains an "Obsolete features manual".  Seriously.

So you probably want to be clear that deprecation means "on the path to
removal" and follow through.  Either by actually removing the code, by
reverting the deprecation, or by inventing a "Discouraged but supported"
(a.k.a. "obsolete") category.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 22-Oct-22 23:22, Dan Fandrich via curl-users wrote:
> 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