[gnutls-devel] GnuTLS | RFC: ephemeral-api: add a mechanism to define ephemeral API (!1199)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Sun Mar 15 09:48:16 CET 2020

Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_305086468

Although I share your concern (as I see `P11_KIT_FUTURE_UNSTABLE_API` defined almost everywhere), I don't think it would cause further problems if we provide a proper deprecation mechanism for old functions:
- if we remove an API (the macro definition in the header), the application wouldn't compile; so they will notice the API is not available and maybe deprecated
- if we remove an underlying implementation, the application _can_ get a dedicated error code upon lookup (not implemented yet); so the user could notice that the application is using an unavailable/deprecated API in a safe manner

If we add a new API, we can always choose a new name, so not to break the existing convention; it would probably be sensible that the initial function name is chosen to be obscure, so it doesn't clash with the final function name

Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_305086468
You're receiving this email because of your account on gitlab.com.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200315/beb24639/attachment.html>

More information about the Gnutls-devel mailing list