ARMmbed/mbedtls
1
0
Fork 0
mirror of https://github.com/ARMmbed/mbedtls.git synced 2025-05-24 23:48:14 +08:00
Code Issues Releases Wiki Activity

Minor clarifications

Browse Source 
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
Gilles Peskine 2021-06-07 20:42:40 +02:00
parent 1483fe4c21
commit d1a8cd5169
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
BRANCHES.md
View File

@ -28,7 +28,7 @@ undocumented features, then you should be able to re-compile it without
modification with any later release x.y'.z' with the same major version modification with any later release x.y'.z' with the same major version
number, and your code will still build, be secure, and work. number, and your code will still build, be secure, and work.
Note that new releases of Mbed TLS may extend the API. Here are some example of changes that are common in minor releases of Mbed TLS, and are not considered compatibility breaks: Note that new releases of Mbed TLS may extend the API. Here are some example of changes that are common in minor releases of Mbed TLS, and are not considered API compatibility breaks:
* Adding or reordering fields in a structure or union. * Adding or reordering fields in a structure or union.
* Removing a field from a structure, unless the field is documented as public. * Removing a field from a structure, unless the field is documented as public.
@ -37,11 +37,11 @@ Note that new releases of Mbed TLS may extend the API. Here are some example of
* Changing which error code is returned in a case where multiple error conditions apply. * Changing which error code is returned in a case where multiple error conditions apply.
* Changing the behavior of a function from failing to succeeding, when the change is a reasonable extension of the current behavior, i.e. the addition of a new feature. * Changing the behavior of a function from failing to succeeding, when the change is a reasonable extension of the current behavior, i.e. the addition of a new feature.
There are rare exceptions: code that was relying on something that became There are rare exceptions where we break API compatibility: code that was
insecure in the meantime (for example, crypto that was found to be weak) may relying on something that became insecure in the meantime (for example,
need to be changed. In case security comes in conflict with backwards crypto that was found to be weak) may need to be changed. In case security
compatibility, we will put security first, but always attempt to provide a comes in conflict with backwards compatibility, we will put security first,
compatibility option. but always attempt to provide a compatibility option.
For the LTS branches, additionally we try very hard to also maintain ABI For the LTS branches, additionally we try very hard to also maintain ABI
compatibility (same definition as API except with re-linking instead of compatibility (same definition as API except with re-linking instead of