## Abstract
-Describes a deprecation policy to properly warn about upcoming removals from the codebase. This policy will be applicable to the following:
+Describes a deprecation schedule to properly warn about upcoming removals from the codebase. This will be applicable to the following:
- `conda/conda`
- `conda/conda-build`
@@ -19,23 +19,19 @@ Other [conda](https://github.com/conda) or [conda-incubator](https://github.com/
## Specification
-We propose a deprecation policy slower than the release cadence (see CEP-?). This is in acknowledgement of our diverse user groups (e.g. everything from per user per machine installs to multi-user installs on shared clusters).
+We propose a deprecation schedule that is slower than the Conda Release Schedule (see CEP-?). This is in acknowledgement of our diverse user groups (e.g. everything from per user per machine installs to multi-user installs on shared clusters).
All deprecations are to be:
-1. initially marked as **pending deprecation** (e.g. using Python's `warnings.PendingDeprecationWarning`) and remain in a pending state for at least 3 releases/months
-2. at the start of the quarter (i.e. in the X.Y.0 release) all **pending deprecations** that have been pending for 3+ releases/months are marked as **deprecations** (e.g. using Python's `warnings.DeprecationWarning`) and remain in a deprecated state for 3 more releases/months
-3. at the start of the following (i.e. in the (X.Y+1).0 release) quarter all **deprecations** that have been deprecated for 3 releases/months are removed
+1. initially marked as **pending deprecation** and remain in a pending state for at least three (3+) `MINOR` releases
+2. January (`YY.1.0`), May (`YY.5.0`), and September (`YY.9.0`) are deprecation releases where:
+ - all **pending deprecations** that have been pending for at least three (3+) `MINOR` releases are marked as **deprecations** and remain in a deprecated state for four (4) `MINOR` releases
+ - all **deprecations** that have been deprecated for four (4) `MINOR` releases are removed
To summarize, features may be marked as **pending deprecation** in any release however **deprecations** and **removals** only occur in the first release of a quarter.
Occasionally there may be code changes that we feel warrant a longer deprecation schedule. If that occurs the deprecation warning will clearly specify that a deviation is occurring and what the expected schedule will be instead.
-In an effort to standardize the deprecation messaging we propose the messaging should look something like the following:
-
-- `f"{__name__}. is pending deprecation in X.Y.0."`
-- `f"{__name__}. will be deprecated in (X.Y+1).0."`
-
## Motivation
Help prevent unexpected breakage of downstream tooling as the codebase evolves.