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

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_305048034

I'm not arguing here for not doing that, my point is about setting the rules of the game, so it is clear when we are introducing unstable APIs, how are applications are supposed to use them (if they are).

For example, my expectation from the "when we introduce such APIs", would be to allow such APIs when used in collaboration with other applications (curl, wget?) to test a new TLS feature. Should we bring unstable APIs when it is not clear who is the actual user of them? I looks risky to me as it looks hard to manage variable expectations. If these APIs are broken after the standard is published, then I'd also expect not to keep compatibility with the old ones (i.e., this instability should not be accumulating technical debt) and the applications these APIs that were targeting should take this into account.

Without setting by documenting these expections, this API although it allows to break the ABI as defined by the .map file, it may not necessary allow us to break that ABI if applications in popular distributions depend on the features introduced by it.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_305048034
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/20200314/32ecd43c/attachment.html>