diff options
| author | David Horstmann <david.horstmann@arm.com> | 2022-11-08 19:13:58 +0000 |
|---|---|---|
| committer | David Horstmann <david.horstmann@arm.com> | 2022-11-08 19:13:58 +0000 |
| commit | 9b1144d5bce4ee8739d884e99811932ab532cc97 (patch) | |
| tree | 7d57a6084da79a65cd5cfeabb8f6edcaad66d200 /CONTRIBUTING.md | |
| parent | c1cc7a4c76cae48453dd70c6ad92f33d192f1667 (diff) | |
| download | mbedtls-9b1144d5bce4ee8739d884e99811932ab532cc97.zip mbedtls-9b1144d5bce4ee8739d884e99811932ab532cc97.tar.gz mbedtls-9b1144d5bce4ee8739d884e99811932ab532cc97.tar.bz2 | |
Minor grammatical fix
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9fee0cb..fc79e49 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -32,7 +32,7 @@ Backwards Compatibility The project aims to minimise the impact on users upgrading to newer versions of the library and it should not be necessary for a user to make any changes to their own code to work with a newer version of the library. Unless the user has made an active decision to use newer features, a newer generation of the library or a change has been necessary due to a security issue or other significant software defect, no modifications to their own code should be necessary. To achieve this, API compatibility is maintained between different versions of Mbed TLS on the main development branch and in LTS (Long Term Support) branches, as described in [BRANCHES.md](BRANCHES.md). -To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release. +To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change. If there is an API change, the contribution, if accepted, will be merged only when there is a major release. No changes are permitted to the definition of functions in the public interface which will change the API. Instead the interface can only be changed by its extension. Where changes to an existing interface are necessary, functions in the public interface which need to be changed are marked as 'deprecated'. If there is a strong reason to replace an existing function with one that has a slightly different interface (different prototype, or different documented behavior), create a new function with a new name with the desired interface. Keep the old function, but mark it as deprecated. |