Back to Documentation

Deprecation Policy

This document outlines Sensei’s code deprecation policy and the timelines for removing deprecated code from the codebase.

Deprecated code is always removed in a major release. The scenarios below assume that there is at least one minor release that contains the deprecation before the major release in which the code is removed.

When to Remove Deprecated Code

Internal Methods

There are two possible scenarios for the deprecation of internal methods:

  • The method has already been marked with @access private or is clearly an internal method (e.g. hooked to the init action). It should be removed in the next major version.
  • The method has not been marked with @access private. It should be removed in the major version after the next one.

Examples include: calls to actions, license renewal notices, and plugin initialization flow (singleton initialization for adding hooks).

Methods Used in Templates & User-Facing Functionality

Removed in the major version after the next one.

Methods Not Used in Templates

Removed in the next major version.

Code Deprecation Process

When deprecating code, the scenarios above can be used to arrive at the major version in which the code will be removed and, if desired, the version can be included in the deprecation notice.

A Github issue for tracking deprecations should be created and attached to the appropriate milestone. A reference to the pull request in which the code was deprecated, and the name of the function/method/hook that is being deprecated, should be added to the issue description. Additional deprecations scheduled for removal in the same release can be appended to the existing issue.