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

Add Moodle 4.4.0 upgrade line to all the upgrade.php scripts

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Minor Minor
    • 4.4.1
    • 4.4, 4.5
    • Installation
    • MOODLE_404_STABLE, MOODLE_405_STABLE
    • MOODLE_404_STABLE
    • MDL-81616-main
    • Hide

      Part 1: Run the "*Command(s) to detect..." mentioned in the description

      1-1: upgrade.php files not having the upgrade line
      1. Run the command to detect all the upgrade.php files not having the upgrade lines:

        find . -name upgrade.php | xargs grep -l 'function.*xmldb_.*_upgrade' | grep '/db/' | xargs grep -L 'Automatically generated Moodle v4.4.0 release upgrade'
        

      2. Confirm that nothing is returned
      1-2: Incorrectly added upgrade lines
      1. Run the following commands to detect that we have not added the lines to incorrect files:

        grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | grep -v '/db/'
        grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | xargs grep -L 'function.*xmldb_.*_upgrade'
        

      2. Confirm that nothing is returned
      1-3: Check upgrade lines added after upgrade steps made after the release
      1. Run the command to detect if the lines have been added after a post-release upgrade step. If there are upgrade steps found verify that all of them were already there on the day of the release and have not been introduced later (you can look for differences between the release v4.4.0 and the current master to verify that)

        export rel="4.4.0" && export ver="202404" &&
        find . -name upgrade.php | \
        xargs grep -B25 "Automatically generated Moodle v${rel} release upgrade" | \
        grep "upgrade_.*_savepoint.*${ver}"
        

      2. Confirm that if any upgrade.php files are returned, the date indicated in the "upgrade_xx_savepoint()" call are not after the 4.4 release date of 20240422.

      Part 2: Check all upgrade scripts with upgrade comment

      1. Check all upgrade scripts have the 4.4.0 comment before the return with:

         find . -ipath '*/db/upgrade.php' | xargs grep -B4 'return true;'
        

        • Random exceptions: Some upgrade scripts could be missing the comments before the return. Surely it's because some new steps already have been introduced after the release. Verify the comments are present in the correct place (before those new steps).

      Part 3

      1. This should return nothing too or the it will return the same exceptions mentioned in Part 2 or in 1-3:

        for u in `find . -name upgrade.php | grep 'db/upgrade'`; do grep -B4 'return true;' "$u" | grep "Automatically generated" > /dev/null; if [ $? -ne 0 ]; then echo "$u"; fi ; done
        

      Part 4

      1. Verify that the differences between the stable branch and master continue being 100% the same after the patch than before it (aka. the patch is 100% the same for both branches). Note that this is not true under parallel development, or when versions already have diverged, so skip this step if that's the case.
      Show
      Part 1: Run the "*Command(s) to detect..." mentioned in the description 1-1: upgrade.php files not having the upgrade line Run the command to detect all the upgrade.php files not having the upgrade lines: find . -name upgrade.php | xargs grep -l 'function.*xmldb_.*_upgrade' | grep '/db/' | xargs grep -L 'Automatically generated Moodle v4.4.0 release upgrade' Confirm that nothing is returned 1-2: Incorrectly added upgrade lines Run the following commands to detect that we have not added the lines to incorrect files: grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | grep - v '/db/' grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | xargs grep -L 'function.*xmldb_.*_upgrade' Confirm that nothing is returned 1-3: Check upgrade lines added after upgrade steps made after the release Run the command to detect if the lines have been added after a post-release upgrade step. If there are upgrade steps found verify that all of them were already there on the day of the release and have not been introduced later (you can look for differences between the release v4.4.0 and the current master to verify that) export rel= "4.4.0" && export ver= "202404" && find . -name upgrade.php | \ xargs grep -B25 "Automatically generated Moodle v${rel} release upgrade" | \ grep "upgrade_.*_savepoint.*${ver}" Confirm that if any upgrade.php files are returned, the date indicated in the " upgrade_xx_savepoint() " call are not after the 4.4 release date of 20240422. Part 2: Check all upgrade scripts with upgrade comment Check all upgrade scripts have the 4.4.0 comment before the return with: find . -ipath '*/db/upgrade.php' | xargs grep -B4 'return true;' Random exceptions: Some upgrade scripts could be missing the comments before the return. Surely it's because some new steps already have been introduced after the release. Verify the comments are present in the correct place (before those new steps). Part 3 This should return nothing too or the it will return the same exceptions mentioned in Part 2 or in 1-3: for u in ` find . -name upgrade.php | grep 'db/upgrade' `; do grep -B4 'return true;' "$u" | grep "Automatically generated" > /dev/null ; if [ $? - ne 0 ]; then echo "$u" ; fi ; done Part 4 Verify that the differences between the stable branch and master continue being 100% the same after the patch than before it (aka. the patch is 100% the same for both branches). Note that this is not true under parallel development , or when versions already have diverged, so skip this step if that's the case.

      In order to have it properly detected for the future it would be great to add to all the upgrade.php scripts some lines like these:

      // Automatically generated Moodle v4.4.0 release upgrade line.
      // Put any upgrade step following this.
      

      exactly before the "return true;" present in all the scripts.

      Normally, it's ok to do that both in the stable (404_STABLE) and master branches, so they will allow quickly find where 4.4.0 started and act once we decide future requirements.

      But, when under parallel development, this only can be done in the stable (404_STABLE) branch, master already has diverged and can have own upgrade steps not corresponding to the version just released, but to the future version being developed in parallel.

      The change can be performed globally with:

      #!/bin/bash
      export rel="4.4.0" && find . -name upgrade.php | \
      xargs grep -l 'function.*xmldb_.*_upgrade' | \
      grep '/db/' | \
      xargs grep -L "Automatically generated Moodle v${rel} release upgrade" | \
      xargs perl -p -i -e 's@( *)(return true;)@\1// Automatically generated Moodle v$ENV{rel} release upgrade line.\n\1// Put any upgrade step following this.\n\n\1\2@s'
      

      Command to detect all the upgrade.php files not having those lines:

      find . -name upgrade.php | xargs grep -l 'function.*xmldb_.*_upgrade' | grep '/db/' | xargs grep -L 'Automatically generated Moodle v4.4.0 release upgrade'
      

      Commands to detect that we have not added the lines to incorrect files:

      grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | grep -v '/db/'
      grep -lr 'Automatically generated Moodle v4.4.0 release upgrade' * | xargs grep -L 'function.*xmldb_.*_upgrade'
      

      Command to detect if the lines have been added after a post-release upgrade step. If there are upgrade steps found verify that all them were already there the day of the release and have not been introduced later (you can look for differences between the release v4.4.0 and current master to verify that)

      export rel="4.4.0" && export ver="202404" &&
      find . -name upgrade.php | \
      xargs grep -B25 "Automatically generated Moodle v${rel} release upgrade" | \
      grep "upgrade_.*_savepoint.*${ver}"
      

      Important note to integrators: The sooner that this issue is integrated after release, the less chances to get the lines put in an incorrect place (that's what the last "command to detect" above tries to avoid. We need to ensure that the lines are exactly in the release point (or we may end deleting upgrade steps incorrectly in the future). So, immediate integration after release (within the on-sync period and ideally before any new upgrade step is added), it the best achievement.

      Ciao

        1. (1) 1 Passed -- (Main)MDL-81616.png
          50 kB
          Kim Jared Lucas
        2. (1) 2 Passed -- (Main)MDL-81616.png
          52 kB
          Kim Jared Lucas
        3. (3) 1 Passed -- (Main)MDL-81616.png
          42 kB
          Kim Jared Lucas
        4. (1) 3 Passed -- (Main)MDL-81616.png
          128 kB
          Kim Jared Lucas
        5. (2) 1 Passed -- (Main)MDL-81616.png
          189 kB
          Kim Jared Lucas

            jpataleta Jun Pataleta
            jpataleta Jun Pataleta
            Huong Nguyen Huong Nguyen
            Shamim Rezaie Shamim Rezaie
            Kim Jared Lucas Kim Jared Lucas
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours, 2 minutes
                2h 2m

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