Moodle has had a regular Long Term Support (LTS) release cycle for quite some time now, but aside from the support period, there has been no real difference between the LTS and non-LTS releases.

An LTS occurs every 4 releases, or approximately every 2 years.

Our current deprecation policy is as follows:

What is Moodle's deprecation policy?

• Deprecations should only be on master, not on stables (exceptions may be made for some external service integrations)
• Deprecations apply to all public APIs, classes, and files.
• Removal of a function, class, or file may only be considered after a minimum of 4 major releases since the deprecation. Example: anything deprecated in 3.2 means that it will be removed in 3.6
• All deprecations should emit debugging notices where possible
• All deprecations should be noted in the relevant upgrade.txt

So, in a nutshell our current deprecation policy has a 4-release cycle too.

This current deprecation policy has several impacts, including:

• removal of deprecated APIs must occur every release
• determining the removal target in documentation is complex and can be impacted by things such as changes to the release schedule, for example:
  • the introduction of Moodle versions 3.10, and 3.11
  • Moodle 4.0 was developed in parallel which confuses the deprecation schedule
  • Moodle 4.0 came after Moodle 3.11, but Moodle 3.0 came after Moodle 2.9 (version numbers are essentially meaningless, sometimes they go up differently)
• the deprecation policy is not aligned with the LTS release cycle
• An API deprecated in one LTS release will be removed before the next LTS release
• plugin developers often support multiple versions of Moodle at the same time within a single branch – with some features deprecated and removed across the Moodle versions that they support

This issue proposes that we change the deprecation policy to be aligned with the LTS release cycle. This is intended to:

• simplify the initial deprecation as there will be a single deprecation target for all issues
• allow plugin developers to have a single branch per LTS release
• reduce the number of releases where final deprecation must happen

For the purposes of clarity I will only detail Proposal D here and will remove previous proposals. Proposal D is an iteration on Proposal B and C which were originally detailed in MDL-55171. That issue was intended to discuss removal of code, as opposed to the current final deprecation process hence I have forked the issue.

Proposal D

This proposal suggests that we change the deprecation policy to be aligned with the LTS release cycle. The short summary is:

Any feature deprecated before an LTS release may be removed in the release after that LTS release.

In real terms this means that in some cases the final deprecation will take place after only 12 months from the release date of the initial deprecation. This is a reduction from the current 24 months.
At the same time it will mean that some features will remain in a deprecated state for up to 30 months, which is an increase from the current 24 months.

This is part of a move towards a more consistent support cycle for Moodle and plugin developers. Other proposals in this collection may include:

• Adjustments to version numbering to form an LTS "Series" - For example:
  • Moodle 5.0, 5.1, 5.2 and 5.3 LTS may form the "Moodle 5 Series"
  • Moodle 6.0, 6.1, 6.2 and 6.3 LTS may form the "Moodle 6 Series"
• limiting dependency and configuration changes which cause a change in compiled output files (CSS, JS, etc) to only impact an LTS series, for example:
  • changes to SCSS dependencies
  • changes to babel dependencies
• a strong recommendation that plugin developers have one branch of their plugin per LTS Series
• removing deprecated features entirely after an appropriate period

This change is intended to create a more stable Moodle with each release in the LTS series getting gradually more and more stable with fewer breaking changes until the LTS release itself.
It is also intended to reduce the maintenance overhead for Moodle core.