Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-52663

Policy: Amend deprecation policy - final removal change

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: Policy
    • Labels:
      None

      Description

      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 Frédéric Massart and Mark Nelson.

      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:

      Previous LTS version Next LTS version Deprecation version Current removal version Proposed removal version New deprecation version?
      2.7 3.1 2.7 2.9 2.9  
      2.7 3.1 2.8 3.0 3.2 YES
      2.7 3.1 2.9 3.1 3.2 YES
      2.7 3.1 3.0 3.2 3.2  
      3.1 3.5 3.1 3.3 3.3  
      3.1 3.5 3.2 3.4 3.6 YES
      3.1 3.5 3.3 3.5 3.6 YES
      3.1 3.5 3.4 3.6 3.6  
      3.5 3.9 3.5 3.7 3.7  
      3.5 3.9 3.6 3.8 4.1 YES
      3.5 3.9 3.7 3.9 4.1 YES
      3.5 3.9 3.8 4.0 4.1  
      3.5 3.9 3.9 4.1 4.1  

      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).

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: