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.
Handling deprecations
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-users <curl-users_at_lists.haxx.se>
Date: Sat, 22 Oct 2022 20:21:41 -0700
I watched Daniel Stenberg's curl://up 2022 presentation (see
https://curl.se/docs/videos/ for links to all available talks) on curl
experiments and how they're handled in the project, during which he
talked about the related problem of how deprecations are handled. That
made me think a bit about how we could better communicate upcoming
deprecations to users.
I recall a few occasions in the past where we've removed some feature
and gotten complaints months (or years) later that we've broken
somebody's use case. Not everybody is subscribed to this relatively
high-traffic mailing list and will read all threads looking for
discussions related to future deprecations, nor do I think it's
reasonable to ask that of everybody. Similarly, asking everybody to
track changes to the DEPRECATIONS.md file on github.com (or in every
released tarball) is something that doesn't really scale when
application maintainers have to track future changes to multiple
dependencies in many different ways.
My suggestions is to add future deprecations to the release notes
already accompanying every release. That file currently contains lists
bug fixes and changes in the current release, so a list of future
changes seems appropriate there. Release notes is the standard way for
interested parties to track what's happening in a program, so it should
provide wider dissemination about what will in the near future end up in
the changes section of that very file and make them visible to more
users.
That would also be the place to list any changes in the upcoming curl 8
release, but I'll move that to a new thread.
Dan
Date: Sat, 22 Oct 2022 20:21:41 -0700
I watched Daniel Stenberg's curl://up 2022 presentation (see
https://curl.se/docs/videos/ for links to all available talks) on curl
experiments and how they're handled in the project, during which he
talked about the related problem of how deprecations are handled. That
made me think a bit about how we could better communicate upcoming
deprecations to users.
I recall a few occasions in the past where we've removed some feature
and gotten complaints months (or years) later that we've broken
somebody's use case. Not everybody is subscribed to this relatively
high-traffic mailing list and will read all threads looking for
discussions related to future deprecations, nor do I think it's
reasonable to ask that of everybody. Similarly, asking everybody to
track changes to the DEPRECATIONS.md file on github.com (or in every
released tarball) is something that doesn't really scale when
application maintainers have to track future changes to multiple
dependencies in many different ways.
My suggestions is to add future deprecations to the release notes
already accompanying every release. That file currently contains lists
bug fixes and changes in the current release, so a list of future
changes seems appropriate there. Release notes is the standard way for
interested parties to track what's happening in a program, so it should
provide wider dissemination about what will in the near future end up in
the changes section of that very file and make them visible to more
users.
That would also be the place to list any changes in the upcoming curl 8
release, but I'll move that to a new thread.
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-10-23