- 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.
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.
|Previous LTS version||Next LTS version||Deprecation version||Current removal version||Proposed removal version||New deprecation version?|
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).