@@ -44,6 +44,31 @@ afraid to use it when it's needed and can help things.
4444- Start simple, refactor as necessary to achieve clean separation of
4545 code, but don't overdo it.
4646
47+ ## Deprecations
48+
49+ Deprecations happen when code no longer fits its purpose or is superseded by better solutions.
50+ In such cases, it's important that deprecations are documented clearly to guide developers during
51+ their upgrade process.
52+
53+ - Add ` @deprecated ` tags in the doc block of deprecated functions, methods, classes, etc. Include
54+ the version number where the deprecation was introduced, a description of why it's deprecated,
55+ and recommended replacement(s), if any. If there are multiple alternative approaches, list all of them.
56+
57+ - Do not add ` @deprecated ` tags to a function/method if you only mean to deprecate its parameter(s).
58+ This will cause the whole function/method to be marked as deprecated by IDEs. Instead, trigger
59+ a deprecation inside the function/method body if those parameters are passed. Ensure to include
60+ the version number since when the deprecation occurred. Optionally, but encouraged, add a ` @todo `
61+ comment so that it can be found later on.
62+
63+ - User-facing deprecation warnings should also be triggered via the framework's deprecation handling
64+ mechanism (e.g., ` @trigger_error() ` or error log entries) to alert end users.
65+
66+ - Do not add new tests for deprecated code paths. Instead, use tools and static analysis to ensure
67+ that no code within the framework or official packages is using the deprecated functionality.
68+
69+ - Document all deprecations in the changelog file for that release, under a "Deprecations"
70+ section, so users are informed when upgrading.
71+
4772## Testing
4873
4974Any new packages submitted to the framework must be accompanied by unit
0 commit comments