[wp-trac] [WordPress Trac] #49957: Adopt a policy to remove deprecated functions

[WordPress Trac]

#49957: Adopt a policy to remove deprecated functions
-------------------------------------+-------------------------------------
 Reporter:  ayeshrajans              |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  General                  |    Version:
 Severity:  normal                   |   Keywords:  2nd-opinion needs-dev-
  Focuses:  docs, performance,       |  note needs-docs needs-codex
  coding-standards                   |
-------------------------------------+-------------------------------------
 One of the things WordPress is known for is its backwards-compatibility.
 You can throw WordPress at pretty much any PHP hosting imaginable, there
 is a very good chance WordPress would run on it.

 The same goes for code that integrated with WordPress. Plugins and themes
 are largely compatible with several WordPress versions.


 When we modernize WordPress, we deprecate functionality by moving them to
 `src/wp-includes/deprecated.php` or `src/wp-admin/includes/deprecated.php`
 files.

 Both of these files as a header:


 {{{
 The functions will be removed in a later version.
 }}}

 I checked if we have _ever_ removed a function from these files, and the
 discoveries were, well, fascinating.


 {{{
 /**
  * Returns or prints a category ID.
  *
  * @since 0.71
  * @deprecated 0.71 Use get_the_category()
  */
 function the_category_ID($echo = true) {
 ...
 }
 }}}

 This is the oldest function we still have in WordPress. WordPress 0.71 was
 released in 2003. There were Concordes flying, George W. Bush was just
 into his second presidency, first iPhone is revealed 4 years after
 WordPress 0.71. To put backwards compatibility to perspective, Microsoft,
 a company known for its good backwards compatibility, stopped support for
 Windows 7 that was released in 2009.

 I think we need to agree to a policy on how long we keep these deprecated
 functions for. Having functions deprecated 17 years ago still in our code
 base is clearly an overkill.

 We don't use interfaces, abstract classes, or otherwise code-enforced
 contracts in WordPress (yet?), so the upgrade process for existing user-
 land code should be pretty easy, as we the deprecation notice often tells
 the new function to use instead of the deprecated one.

 Even if we consider every major (not in a semantic versioning sense)
 WordPress such as 5.3, 5.4 and 5.5 as LTS version, I have only seen
 software providing compatibility for upto 5 years (Ubuntu LTS releases for
 example).


 Note that both of these files are included by default, and a routine
 clean-up means we reword users who update frequently with light-weight
 code. This is the segment of users that we should reward anyway. If a
 certain plugin absolutely, must, adamantly, and and uncompromisingly need
 to use a function, they can poly-fill those functions in the plugins own
 code based with plugin name prefix. This is not a practice that we should
 encourage though.

 **Proposal**

 We should not be needing to open a ticket every time we need to remove a
 deprecated function. A policy adopted means we roughly know when and how
 the deprecated code should be purged.

 I would like to propose that we agree to a policy on how long we keep the
 deprecated functions in the code base, and my personal vote would be **5
 years**.

 5 years is a plenty of time to upgrade existing plugins and themes, and if
 a theme/plugin did not receive updates for 5 years, there is a very good
 chance that they have security vulnerabilities and major bugs.

 **Statistics**

 To put this 5 year policy to perspective, this leaves WordPress 4.1 and
 older versions out. Here is a break-down on when functions were
 deprecated.


 ||Version deprecated in||`deprecated.php`||`admin deprecated.php`||total||
 ||0.x||2||0||2||
 ||1.x||3||0||3||
 ||2.x||87||5||92||
 ||3.x||57||59||116||
 ||4.0||3||0||3||
 ||4.1||0||0||0||
 ||>4.1||29||8||37||
 ||**Grand total**||**181**||**72**||**253**||
 ||**Deprecated >5 years ago**||**152**||**64**||**216**||



 This can lead to removal of polyfills (such as the recently removed SPL
 polyfill) and help us keep up with WordPress and PHP modernization.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49957>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform