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

Policy: Amend deprecation policy - final removal change

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 3.1
    • None
    • Policy
    • 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 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:

      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

              marina Marina Glancy
              dobedobedoh Andrew Lyons
              David Woloszyn, Huong Nguyen, Jake Dallimore, Michael Hawkins, Stevani Andolo
              Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: