|
| 1 | +# API and Deprecation Policy |
| 2 | + |
| 3 | +## API Policy |
| 4 | + |
| 5 | +The code in this library is intended to be called by other projects. It is not |
| 6 | +intended to be extended. If you want to extend any classes, you're on your own, |
| 7 | +and your code might break with any new release of this library. |
| 8 | + |
| 9 | +Any classes, methods and properties that are `public` and not marked as |
| 10 | +`@internal` are considered to be part of the API. Those methods will continue |
| 11 | +working in a compatible way over minor and bug-fix releases according |
| 12 | +to [Semantic Versioning](https://semver.org/), though we might change the native |
| 13 | +type declarations in a way that could break subclasses. |
| 14 | + |
| 15 | +Any classes, methods and properties that are `protected` or `private` are _not_ |
| 16 | +considered part of the API. Please do not rely on them. If you do, you're on |
| 17 | +your own. |
| 18 | + |
| 19 | +Any code that is marked as `@internal` is subject to change or removal without |
| 20 | +notice. Please do not call it. There be dragons. |
| 21 | + |
| 22 | +If a class is marked as `@internal`, all properties and methods of this class |
| 23 | +are by definition considered to be internal as well. |
| 24 | + |
| 25 | +When we change some code from public to `@internal` in a release, the first |
| 26 | +release that might change that code in a breaking way will be the next major |
| 27 | +release after that. This will allow you to change your code accordingly. We'll |
| 28 | +also add since which version the code is internal. |
| 29 | + |
| 30 | +For example, we might mark some code as `@internal` in version 8.7.0. The first |
| 31 | +version that possibly changes this code in a breaking way will then be version |
| 32 | +9.0.0. |
| 33 | + |
| 34 | +Before you upgrade your code to the next major version of this library, please |
| 35 | +update to the latest release of the previous major version and make sure that |
| 36 | +your code does not reference any code that is marked as `@internal`. |
| 37 | + |
| 38 | +## Deprecation Policy |
| 39 | + |
| 40 | +Code that we plan to remove is marked as `@deprecated`. In the corresponding |
| 41 | +annotation, we also note in which release the code will be removed. |
| 42 | + |
| 43 | +When we mark some code as `@deprecated` in a release, we'll usually remove it in |
| 44 | +the next major release. We'll also add since which version the code is |
| 45 | +deprecated. |
| 46 | + |
| 47 | +For example, when we mark some code as `@deprecated` in version 8.7.0, we'll |
| 48 | +remove it in version 9.0.0 (or sometimes a later major release). |
| 49 | + |
| 50 | +Before you upgrade your code to the next major version of this library, please |
| 51 | +update to the latest release of the previous major version and make sure that |
| 52 | +your code does not reference any code that is marked as `@deprecated`. |
0 commit comments