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

PRE: Minimum changes in code to work with parallel branches

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.10, 4.0
    • Fix Version/s: 3.10
    • Component/s: General, Installation
    • Labels:
    • Testing Instructions:
      Hide

      Requirements: To be tested by a developer.

      master-only. The versions bump.

      A) Definition: "VERSION" == 2021052500 (2w after 3.11 release)
      B) Definition: "REQUIRE" == 2021052500 (2w after 3.11 release)

      1) TEST: Visually verify that all the changes in the patch point to the correct "VERSION" versions and all the requires and dependencies point to the correct "REQUIRE" and nothing else is changed. Note main version.php file must be >= "REQUIRE". Any dependency using the ANY_VERSION constant should remain unchanged by the patch.

      2) Upgrade from 3.9.x version using the web interface

      • TEST: In the plugins screen ALL the plugins are showing "to upgrade".
      • TEST: All the target versions show "VERSION" and all the dependencies show the "REQUIRE" version along the whole page.
      • TEST: Run upgrade. Ends without error.

      3) Verify that there isn't any plugin version.php file missing the "VERSION". Something like this should do the trick (ignore main version.php, that's ok, will be updated on release day):

      find . -name version.php | grep -v fixtures | xargs grep -L VERSION
      

      4) Verify that there isn't any plugin version.php containing a comment with anything looking like a numeric version. Can be verified by checking that there aren't cases returned by:

      find . -name version.php | xargs grep -P '; *\/.*[0-9.]{3}'
      

      5) Verify that there isn't any plugin->release in core, it's no sense there. Can be verified running:

      find . -name version.php | xargs grep -P '>release' | grep -v fixtures
      

      6) TEST: To integrators, minutes after integration, verify the "Check version.php files (master)" job in the integration server ends without error, that everything points to "VERSION" / "REQUIRE" versions and that the report does not include any "ERROR" looking to the generated "versions_check_set.txt" file in the workspace. Note some "WARN" can exist. But that's not relevant for this issue.
      ^^^ As commented below, expect all versions (all components) to be failing till MDLSITE-6224 is completed.

      MOODLE_310_STABLE and master

      1) Verify That can install a MOODLE_310_STABLE version from scratch.
      2) Install Moodle 3.5.x (using PHP 7.2)
      3) Verify that can upgrade to Moodle 3.10dev

      All branches

      1) Just verify that automated tests are passing, that should be enough.

      Show
      Requirements: To be tested by a developer. master-only. The versions bump. A) Definition: "VERSION" == 2021052500 (2w after 3.11 release) B) Definition: "REQUIRE" == 2021052500 (2w after 3.11 release) 1) TEST: Visually verify that all the changes in the patch point to the correct "VERSION" versions and all the requires and dependencies point to the correct "REQUIRE" and nothing else is changed. Note main version.php file must be >= "REQUIRE". Any dependency using the ANY_VERSION constant should remain unchanged by the patch. 2) Upgrade from 3.9.x version using the web interface TEST: In the plugins screen ALL the plugins are showing "to upgrade". TEST: All the target versions show "VERSION" and all the dependencies show the "REQUIRE" version along the whole page. TEST: Run upgrade. Ends without error. 3) Verify that there isn't any plugin version.php file missing the "VERSION". Something like this should do the trick (ignore main version.php, that's ok, will be updated on release day): find . -name version.php | grep -v fixtures | xargs grep -L VERSION 4) Verify that there isn't any plugin version.php containing a comment with anything looking like a numeric version. Can be verified by checking that there aren't cases returned by: find . -name version.php | xargs grep -P '; *\/.*[0-9.]{3}' 5) Verify that there isn't any plugin->release in core, it's no sense there. Can be verified running: find . -name version.php | xargs grep -P '>release' | grep -v fixtures 6) TEST: To integrators, minutes after integration, verify the "Check version.php files (master)" job in the integration server ends without error, that everything points to "VERSION" / "REQUIRE" versions and that the report does not include any "ERROR" looking to the generated "versions_check_set.txt" file in the workspace. Note some "WARN" can exist. But that's not relevant for this issue. ^^^ As commented below, expect all versions (all components) to be failing till MDLSITE-6224 is completed. MOODLE_310_STABLE and master 1) Verify That can install a MOODLE_310_STABLE version from scratch. 2) Install Moodle 3.5.x (using PHP 7.2) 3) Verify that can upgrade to Moodle 3.10dev All branches 1) Just verify that automated tests are passing, that should be enough.
    • Affected Branches:
      MOODLE_310_STABLE, MOODLE_400_STABLE
    • Fixed Branches:
      MOODLE_310_STABLE
    • Pull 3.8 Branch:
    • Pull 3.9 Branch:
    • Pull 3.10 Branch:
      MDL-69475_310
    • Pull Master Branch:

      Description

      Once MDLSITE-6220 has been performed and we, effectively have the 2 development branches created, there are a few things we need to adjust:

      1. Move to 3-digits $branch in main version.php. And apply the minimum changes is core to support them. Any version > 3.9.x will have 3-digit branches.
      2. Effectively diverge the 2 dev branches, that implies bumping all versions in master to a "safe" date (a date that none of the planned dev branches (310 and 311) are going to use ever (we'll use the version checker itself to do this, see MDL-68973 as reference).

      Note1: The changes in core are not aiming to be complete (this is a PRE issue). Just the minimum to get the branches installed and tested. If other dependencies are found, new issues will be created.

      Note2: This may create some interim failures in the version checker that will be solved by MDLSITE-6224

        Attachments

        1. screenshot-1.png
          screenshot-1.png
          123 kB
        2. screenshot-2.png
          screenshot-2.png
          48 kB
        3. screenshot-3.png
          screenshot-3.png
          13 kB
        4. screenshot-4.png
          screenshot-4.png
          38 kB
        5. screenshot-5.png
          screenshot-5.png
          64 kB

          Issue Links

            Activity

              People

              Assignee:
              stronk7 Eloy Lafuente (stronk7)
              Reporter:
              stronk7 Eloy Lafuente (stronk7)
              Integrator:
              Adrian Greeve
              Tester:
              David Mudrák (@mudrd8mz)
              Participants:
              Component watchers:
              Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias, Matteo Scaramuccia, Andrew Nicols, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Fix Release Date:
                9/Nov/20

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 4 hours, 36 minutes
                  4h 36m