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

[Development of GNU's TLS library]

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>