Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: What's changing in curl 8
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Sun, 23 Oct 2022 12:53:21 +0200 (CEST)
On Sat, 22 Oct 2022, Dan Fandrich via curl-users wrote:
> 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.
In general I have tried to be a little bit more pragmatic and applied the
rule: if *nobody* notices a behavior change, then it isn't a behavior change.
> 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.
I think removing them would bring a larger burden than keeping them, for a
fair amount of time into the future.
If we remove function calls and bump the SONAME, for a very long time into the
future people will learn about these removals the hard way (link errors after
upgrades) and come to us to complain, asking us to bring them back and with
questions on how they can bring back the functionality themselves. Could
possibly also force us or someone else to create a legacy fork to maintain
with various things kept.
> 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!
I expect this to be a virtually unnoticed requirement because I guess that not
even 0.1% of our users actually build curl on a system without a 64 bit type
present.
> 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.
What would a soft removal mean in practical terms? Removing the prototype will
cause build warnings/errors for users. Changing API but keeping the ABI ?
Personally I have pretty much "given up" on the idea of ever bumping SONAME
again but hey, nothing is forever and I can change as well.
In practical terms, we have tried to add stuff to DEPRECATE.md so that they
are mentioned in there *at least* six months (from a release) until they are
actually removed - to allow people to complain, react and adapt. And we are
now already less than six months from 8.0.0!
> 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).
In my experience, the people who build their own libcurl like for use in their
own devices, tools and things, are already disabling features and stuff to
reduce foot-print and error surface. That's one of the reasons why I think we
should keep providing switches to allow enable/disable of specific features at
build-time. Disabling features like this *does* break the ABI, but then that
is up to the ones doing the build to take that responsibility.
The ones who build libcurl for platforms (say linux distros) I believe are
less likely to use anything like this as they rather maximize compatiblity.
> 9. Allow use of C99 features in the source code.
When I brought up that topic a while ago I sensed very little desire for C99
features. If we go C99, I think we should do it in a controlled manner and
only allow certain things, maybe gradually allowing more, so that we don't go
all in and crazy at once.
I've also followed the C99 usage discussion in the git project for
inspiriation. They also ran into issues with certain compilers still in use
that don't support all C99 features satisfyably.
I don't think we need to do this step for v8.
> 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.
Right now we have things at several different levels of "deprecation" and that
is of course less than ideal and not easy for anyone to actually understand or
figure out. As not even we ourselves do!
So yes, a clearer message and better information on what exactly every mention
of "deprecation" means would be really good.
Date: Sun, 23 Oct 2022 12:53:21 +0200 (CEST)
On Sat, 22 Oct 2022, Dan Fandrich via curl-users wrote:
> 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.
In general I have tried to be a little bit more pragmatic and applied the
rule: if *nobody* notices a behavior change, then it isn't a behavior change.
> 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.
I think removing them would bring a larger burden than keeping them, for a
fair amount of time into the future.
If we remove function calls and bump the SONAME, for a very long time into the
future people will learn about these removals the hard way (link errors after
upgrades) and come to us to complain, asking us to bring them back and with
questions on how they can bring back the functionality themselves. Could
possibly also force us or someone else to create a legacy fork to maintain
with various things kept.
> 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!
I expect this to be a virtually unnoticed requirement because I guess that not
even 0.1% of our users actually build curl on a system without a 64 bit type
present.
> 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.
What would a soft removal mean in practical terms? Removing the prototype will
cause build warnings/errors for users. Changing API but keeping the ABI ?
Personally I have pretty much "given up" on the idea of ever bumping SONAME
again but hey, nothing is forever and I can change as well.
In practical terms, we have tried to add stuff to DEPRECATE.md so that they
are mentioned in there *at least* six months (from a release) until they are
actually removed - to allow people to complain, react and adapt. And we are
now already less than six months from 8.0.0!
> 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).
In my experience, the people who build their own libcurl like for use in their
own devices, tools and things, are already disabling features and stuff to
reduce foot-print and error surface. That's one of the reasons why I think we
should keep providing switches to allow enable/disable of specific features at
build-time. Disabling features like this *does* break the ABI, but then that
is up to the ones doing the build to take that responsibility.
The ones who build libcurl for platforms (say linux distros) I believe are
less likely to use anything like this as they rather maximize compatiblity.
> 9. Allow use of C99 features in the source code.
When I brought up that topic a while ago I sensed very little desire for C99
features. If we go C99, I think we should do it in a controlled manner and
only allow certain things, maybe gradually allowing more, so that we don't go
all in and crazy at once.
I've also followed the C99 usage discussion in the git project for
inspiriation. They also ran into issues with certain compilers still in use
that don't support all C99 features satisfyably.
I don't think we need to do this step for v8.
> 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.
Right now we have things at several different levels of "deprecation" and that
is of course less than ideal and not easy for anyone to actually understand or
figure out. As not even we ourselves do!
So yes, a clearer message and better information on what exactly every mention
of "deprecation" means would be really good.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-10-23