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

Minimum changes in code to start working with parallel branches (3.10)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • 3.10
    • 3.10, 4.0
    • General, Installation
    • MOODLE_310_STABLE, MOODLE_400_STABLE
    • MOODLE_310_STABLE
    • 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.

      This issue include all the changes needed in core to start working with parallel branches, aka. when a parallel development period is already in effect and we are creating a new XXX_STABLE (310n this case) development branch.

      It's important to comment that this case is more complex than the changes needed to continue working with parallel branches (see MDL-70229). In that case it's not needed to perform any change of versions to master, because they have been already planned and performed here.

      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, so we ensure no overlapping will hapeen (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

        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

            stronk7 Eloy Lafuente (stronk7)
            stronk7 Eloy Lafuente (stronk7)
            Adrian Greeve Adrian Greeve
            David Mudrák (@mudrd8mz) David Mudrák (@mudrd8mz)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved:

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

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.