|
| 1 | +Workflow for Deprecating Features in CPython |
| 2 | +============================================== |
| 3 | + |
| 4 | +Deprecation in CPython is a multi-step process that involves notifying users about deprecated functionality, planning its eventual removal, and providing adequate guidance for migration. |
| 5 | +This document outlines the practical steps required for deprecating a feature, supplementing the policy guidelines defined in :pep:`387`. |
| 6 | + |
| 7 | +1. Identify Features for Deprecation |
| 8 | +------------------------------------ |
| 9 | +Before proposing deprecation: |
| 10 | + |
| 11 | +* **Assess Usage**: Use tools like GitHub search, `grep`, or PyPI statistics to determine the extent and context of usage. |
| 12 | +* **Consider Alternatives**: Ensure there are suitable replacements or upgrades available. |
| 13 | + |
| 14 | +2. Open an Issue |
| 15 | +---------------- |
| 16 | +Start by creating a GitHub issue to propose the deprecation: |
| 17 | + |
| 18 | +* Clearly describe the feature and why deprecation is needed. |
| 19 | +* Encourage community feedback and suggestions. |
| 20 | + |
| 21 | +3. Deprecation Implementation |
| 22 | +----------------------------- |
| 23 | +Once approved: |
| 24 | + |
| 25 | +* **Raise a Warning**: Use :func:`warnings.warn` with :exc:`DeprecationWarning` for typical cases. |
| 26 | + If the feature is in its early deprecation phase: |
| 27 | + |
| 28 | + * Use :exc:`PendingDeprecationWarning` initially, which transitions to :exc:`DeprecationWarning` after a suitable period. |
| 29 | + |
| 30 | + Example: |
| 31 | + |
| 32 | + .. code-block:: python |
| 33 | +
|
| 34 | + import warnings |
| 35 | + warnings.warn( |
| 36 | + "Feature X is deprecated and will be removed in Python 3.Y", |
| 37 | + DeprecationWarning, |
| 38 | + stacklevel=2 |
| 39 | + ) |
| 40 | +
|
| 41 | +* **Update Documentation**: |
| 42 | + |
| 43 | + * Add a deprecation note in the relevant docstrings. |
| 44 | + * Include details in the "Porting" section of the "What's New" documentation. |
| 45 | + * Update the ``pending-removal-in-{version}.rst`` file with the deprecation timeline. |
| 46 | + |
| 47 | +4. Track Deprecations |
| 48 | +--------------------- |
| 49 | +* **Monitor Usage**: After the release, observe community feedback. Deprecations may remain longer than the minimum period if low maintenance overhead is expected or usage is widespread. |
| 50 | +* **Timeline Review**: Use GitHub milestones or specific deprecation tracking issues to manage timelines. |
| 51 | + |
| 52 | +5. Plan Removal |
| 53 | +--------------- |
| 54 | +After the deprecation period (typically 2+ releases): |
| 55 | + |
| 56 | +* Open a new issue for removal. |
| 57 | +* Follow removal steps: |
| 58 | + |
| 59 | + * Remove the deprecated code and warnings. |
| 60 | + * Update documentation, removing references to the deprecated feature. |
| 61 | + * Include the removal in the "What's New" for the release. |
| 62 | + |
| 63 | +6. PendingDeprecationWarning Workflow |
| 64 | +------------------------------------- |
| 65 | +For gradual deprecations: |
| 66 | + |
| 67 | +* **Use Case**: When you want to signal future deprecation but not yet alert end-users. |
| 68 | +* **Transition Timeline**: |
| 69 | + |
| 70 | + * Move from :exc:`PendingDeprecationWarning` to :exc:`DeprecationWarning` after one or more releases. |
| 71 | + |
| 72 | +* **Documentation**: |
| 73 | + |
| 74 | + * Mention the pending deprecation in “What’s New.” |
| 75 | + * No ``pending-removal-in`` entry is needed during this stage. |
| 76 | + |
| 77 | +7. References and Templates |
| 78 | +--------------------------- |
| 79 | +* Use ``.. deprecated::`` and ``.. removed::`` Sphinx roles for documentation. |
| 80 | +* Add ``See Also`` links to :pep:`387` and DevGuide for policy and process details. |
0 commit comments