Decision:

• keep 2 version in Moodle 3.1
• starting from 3.2 change final deprecation from 2 to 4 versions

Which will also mean that if we do everything without delays:

• deprecated in 2.8 was finalised in 3.0
• deprecated in 2.9 will be finalised in 3.1
• deprecated in 3.0 will be finalised in 3.4
• deprecated in 3.1 will be finalised in 3.5
  and so on.

This just came up in a discussion with fred and markn.

Our Deprecation policy which fits into two categories:
1) Immediate action: Mark the item as deprecated but ensure that it continues to work (preferably passing through to the old system); and
2) Final deprecation: Actual removal of the code.

We currently perform the final deprecation component at deprecation target + 2 versions.
So if we deprecate something for the Moodle 2.7.0 release, it will be be processed for final deprecation/removal in Moodle 2.9.0.

However, this is slightly at-odds with our LTS release cycle.
Our last LTS release was Moodle 2.7, and our next LTS release will be Moodle 3.1.

If a deprecation occurs in Moodle 2.8, or Moodle 2.9, then we will process the removals in Moodle 3.0, and Moodle 3.1 respectively.
What this means is that a user upgrading from LTS to LTS may have entire components disappear with no debugging information.

I'd like to propose that we modify the final deprecation component slightly such that:

• If a deprecation happens such that deprecation notices are displayed in the current LTS, then there is no change; and
• If a deprecation happens such that deprecation notices are only displayed in versions released after the current LTS, the removal version is changed to LTS + 1 release. This means that a deprecation in 2.8, or 2.9 would both be finally removed in 3.2.

Some example:

Fred tells me that Django have recently made a similar change (details at https://docs.djangoproject.com/en/1.9/internals/release-process/#deprecation-policy).