-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename functions whose deprecated variant has been removed #4212
Comments
Initial list of functions concerned, as a discussion starter (the final list will be produced as part of #4029):
|
My initial opinion was that we generally want to rename, but Gilles pointed out that in some cases we might not. Looking at the above list, I'm revising my initial impression:
|
One consideration is: what migration path do we offer for applications written for the 2.x API? “We don't have time, just let each developer cope” is not a good answer: this is work that all applications will need to do, so the Mbed TLS project should offer a solution that works for most people. It doesn't have to be Arm doing it, but it has to ship in Mbed TLS. Given the tight timeline for 3.0, I don't think we can count on having a solution by the time of the 3.0 release, regardless of who does the work. Therefore I propose the following guideline: a typical application that does not use any deprecated feature and does not rely on internal details such as structure content should keep working. As a consequence, the old names should remain available in 3.0. We can declare them as informally deprecated synonyms of new names, to be deprecated later once a renaming tool is available. |
I think that's an excellent point. I also agree that it can easily be achieved (when we'd like to rename) by providing a simple |
Team decision: do the renaming and provide a header with |
Proposal:
|
This is a follow-up to #4029 which is about removing deprecated things, in particular deprecated functions.
In the 2.x branch when we found that a function's prototype turned out not to be satisfying, one common pattern to fix this was to (a) add a new function with a better prototype and a new name (often just adding
_ext
or_ret
to the original name) and (b) deprecated the old function.In those cases, once the old function has been removed as part of #4029, it becomes possible to use a more natural name for the (new) remaining function, by removing the suffix. This task is to determine for which functions such a renaming is desirable, and create further tasks to track execution of the renamings that were deemed desirable.
The text was updated successfully, but these errors were encountered: