Skip to main content

CEP 9 - Conda Deprecation Schedule

Title Conda Deprecation Schedule
Status Accepted
Author(s) Ken Odegard <kodegard@anaconda.com>, Jannis Leidel <jleidel@anaconda.com>, Travis Hathaway <thathaway@anaconda.com>
Created May 20, 2022
Updated September 20, 2022
Discussion https://github.com/conda-incubator/ceps/pull/27
Implementation NA

Abstract

This CEP describes a deprecation schedule to properly warn about upcoming removals from the codebase. This policy expands on ideas and terminology defined in the Conda Release Schedule (CEP 8).

Note This CEP is only applicable for projects that have adopted the Conda Release Schedule (CEP 8).

Specification

We propose a deprecation schedule that is slower than the Conda Release Schedule (CEP 8). This is in acknowledgment of our diverse user groups (e.g. everything from per user per machine installs to multi-user installs on shared clusters).

We define a new type of release, a deprecation release, to augment regular releases. A deprecation release occurs twice every year in March and September:

VersionRelease Type
YY.1.0regular
YY.2.0optional
YY.3.0regular, deprecation
YY.4.0optional
YY.5.0regular
YY.6.0optional
YY.7.0regular
YY.8.0optional
YY.9.0regular, deprecation
YY.10.0optional
YY.11.0regular
YY.12.0optional

All deprecations will need to transition through three (3) states:

  1. Pending deprecation: when a feature is marked for future deprecation
    • Any feature can be marked as pending deprecation in any release
    • This state is also a comment period where community concerns or disputes may be raised, see Disputing a Deprecation
  2. Deprecated: when a feature is marked for future removal
    • All pending deprecations that have been through at least two (2+) regular release (4-9 months after being marked as pending deprecation) are relabeled as deprecated in the next deprecation release
    • This state is considered final, the deprecation will occur, disputes are no longer possible, see Disputing a Deprecation
  3. Removed: when a feature is removed from the codebase
    • All deprecations are removed in the next deprecation release

This would result in the following schedule:

Occasionally, there may be changes to the codebase that 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.

Disputing a Deprecation

The pending deprecation state is also a comment period whereby disputes for the deprecation may be raised.

To raise a dispute, open an issue on the relevant repository with the following details:

  1. Which pending deprecation feature to dispute
  2. Details and explanation for why the pending deprecation shouldn't proceed

It's up to the repository maintainers to engage in the discussion, resolve concerns, or ultimately revert the pending deprecation status.

Should the dispute reach an impasse, the steering council must vote on the resolution following the standard voting procedure of an enhancement proposal.

Motivation

This CEP will help prevent unexpected breakage of downstream tooling as the codebase evolves.

Backwards Compatibility

This is backwards compatible and will also encourage better backwards compatibility.

Alternatives

  1. Ad hoc deprecations.
    • Unpredictable and unreliable.
  2. Mark as pending deprecation in one release, mark as a deprecated in the next release, and remove in third release.
    • Rejected for being too rapid given the sprawling ecosystem and unknown number of downstream applications.

Resolution

This section contains the final decision on this issue.

Reference

All CEPs are explicitly CC0 1.0 Universal.