API Life Cycle and Deprecation Policy (original) (raw)
API Life Cycle#
Each API of ExecuTorch falls into one of the following life cycle states:
Experimental
- APIs in this stage are under active development and may change or be removed at any time. That said, the expectation is that we will eventually promote it to Stable, unless sufficient negative signals have been collected from the community or better alternatives have been found.
- Experimental APIs will be clearly marked (see the “How to Mark API State” section below).
- Experimental APIs may be changed or removed without notice, and developers should expect no stability guarantees.
Stable
- APIs are considered to be Stable if they are not marked as Experimental or_Deprecated._
- APIs in this stage have been thoroughly tested and are considered ready for production use.
- The recommended best practice is to not deprecate stable APIs. When writing an API, write it in such a way that it doesn’t need to be deprecated in the future.
- Stable APIs can be changed, but not in a breaking way. If breaking changes have to be made, Stable APIs will always transition to Deprecated before being broken/removed from the library.
Deprecated
- APIs in this stage are no longer recommended for use and will be removed in a future version of ExecuTorch.
- Deprecated APIs will be clearly marked (see the “How to Mark API State” section below).
- Deprecated APIs will remain functional for at least the deprecation period(see the “Deprecation Period” section below) to allow developers time to migrate to alternative APIs.
Deleted
- APIs whose removal are made permanent. Cleaned up from both code and documentation.
Deprecation Policy#
Follow these steps to deprecate and remove an API:
- Discuss the change and collect initial feedback.
- Clearly mark the API deprecated in code and documentation (See “How to Mark API State” below).
- Listen to user feedback after the first release that deprecates the API. Users who weren’t involved in the original discussion may have good arguments for not deprecating or removing the API.
- Once the deprecation period has passed, the API may be removed (See “Deprecation Period” below). Be sure to also remove references from the documentation.
We also use deprecation as a way to make breaking changes to an existing interface: for example, if adding a non-optional parameter to a method. To do this without breaking existing users:
- In a single commit:
- Create a new API that meets the new requirements.
- Deprecate the old API and recommend that users move to the new API.
- Migrate use cases from the old API to the new API.
- Delete the old API after the deprecation period.
How to Mark API State#
When possible, the ExecuTorch code uses language-standard ways to annotate API lifecycle state in the code. This makes it easier for IDEs and other tools to communicate state to developers.
| Language | Code | Documentation |
|---|---|---|
| Python | Use theexecutorch.exir._warnings.deprecateddecorator. Use theexecutorch.exir._warnings.experimentaldecorator. | Use .. warning:: in the docstrings of deprecated and experimental APIs. Seeexample usage. |
| C++ | Use the ET_DEPRECATED annotation macro. See example usage. Use the ET_EXPERIMENTAL annotation macro. | Start Doxygen comments with DEPRECATED: Seeexample usage. Start Doxygen comments with EXPERIMENTAL:. |
| Java | Use java.lang.Deprecated. Use androidx.annotation.RequiresOptIn. | /** * @deprecated Use {@link #newMethod()} instead. */ /** * Warning: This API is experimental. */ |
| Objective-C | __attribute__((deprecated("Use newMethod instead"))); __attribute__((deprecated("This API is experimental and may change without notice."))); | /** * @deprecated Use `newMethod` instead. */ /** * @experimental This API is experimental. */ |
| Swift | @available(*, deprecated, message: "Use newMethod instead") @available(*, message: "This API is experimental") | /// - Warning: Deprecated. Use `newMethod()` instead. /// - Warning: This API is experimental. |
The annotations would trigger static and/or runtime warning that contains at least these information:
- Clearly point to the non-deprecated alternative to migrate to, or be clear if there is no alternative;
- Specify the earliest version in which the API may actually be removed (See “Deprecation Period” below).
Deprecation Period#
Here we recommend waiting for at least 2 minor releases before the removal. For example, if a function is marked as deprecated in release 1.3.x, then it can be deleted in 1.5.x or later.