Details

    Description

      https://buildbot.mariadb.org/#/builders/601/builds/342

      + old_branch_digit=10
      ++ cut -d . -f2
      + old_major_digit=11
      ++ cut -d . -f1
      + new_branch_digit=11
      ++ cut -d . -f2
      + new_major_digit=5
      + (( old_branch_digit == 10 ))
      + (( old_major_digit == 11 ))
      + (( new_branch_digit == 11 ))
      + (( new_major_digit != 0 ))
      + bb_log_err 'This does not look like a major upgrade from 10.11 to 11.0:'
      + set +x
      ERROR: This does not look like a major upgrade from 10.11 to 11.0:
      + diff -u /tmp/version.old /tmp/version.new
      --- /tmp/version.old	2024-05-30 21:17:46.860501015 +0000
      +++ /tmp/version.new	2024-05-30 21:19:30.987997495 +0000
      @@ -1 +1 @@
      -10.11.6
      +11.5.2
      + exit 1
      

      scripts/bash_lib.sh

      Attachments

        Activity

          rvarzaru can you check if this is still needed. I don't see 10.11 upgrade to 11.0 in BB so I believe that this could be closed but please confirm.

          faust Faustin Lammler added a comment - rvarzaru can you check if this is still needed. I don't see 10.11 upgrade to 11.0 in BB so I believe that this could be closed but please confirm.
          rvarzaru Varzaru Razvan-Liviu added a comment - - edited

          faust a bit hard to check what is wrong without a description of what is wrong.
          These being said, this is the logic right now for Major upgrades, something like:

          ...
          10.5 > 10.6
          ...
          10.10 > 10.11
          10.11 -> 11.0
          11.0 -> 11.1
          ...
          11.8 > 12.0

          This is the concept of upgrading from previous major version.
          If the reporter danblack agrees then this task is not relevant.
          If the concept is wrong, a better description would be nice!

          upgrade_test_type() {
            case $1 in
              "minor")
                prev_major_version=$major_version
                ;;
              "major")
                major=${major_version%.*}
                # intentionally twice, 11.5.3 has minor of 5.
                minor=${major_version##*.}
                minor=${major_version##*.}
                # with the earliest supported 11.X version
                # and make this the upgrade from 10.11
                if [ "$minor" -le 1 ]; then
                  if ((major == 11)); then
                    prev_major_version="10.11"
                  else
                    bb_log_err "Unknown previous branch for $branch_tmp, please update this script"
                    exit 1
                  fi
                else
                  prev_major_version="$major.$((minor - 1))"
                fi
                ;;
          

          rvarzaru Varzaru Razvan-Liviu added a comment - - edited faust a bit hard to check what is wrong without a description of what is wrong. These being said, this is the logic right now for Major upgrades, something like: ... 10.5 > 10.6 ... 10.10 > 10.11 10.11 -> 11.0 11.0 -> 11.1 ... 11.8 > 12.0 This is the concept of upgrading from previous major version. If the reporter danblack agrees then this task is not relevant. If the concept is wrong, a better description would be nice! upgrade_test_type() { case $ 1 in "minor" ) prev_major_version=$major_version ;; "major" ) major=${major_version%.*} # intentionally twice, 11.5 . 3 has minor of 5 . minor=${major_version##*.} minor=${major_version##*.} # with the earliest supported 11 .X version # and make this the upgrade from 10.11 if [ "$minor" -le 1 ]; then if ((major == 11 )); then prev_major_version= "10.11" else bb_log_err "Unknown previous branch for $branch_tmp, please update this script" exit 1 fi else prev_major_version= "$major.$((minor - 1))" fi ;;

          Now, given that we don't have 11.0 builds anymore,
          I can check the logic for a major upgrade in the 11.x series, which does look sane.

          https://buildbot.mariadb.org/#/builders/443/builds/2001/steps/3/logs/stdio

          + check_upgraded_versions
          + for file in /tmp/version.old /tmp/version.new
          + [[ -f /tmp/version.old ]]
          + for file in /tmp/version.old /tmp/version.new
          + [[ -f /tmp/version.new ]]
          + [[ major == \m\a\j\o\r ]]
          ++ cut -d . -f1
          + old_branch_digit=11
          ++ cut -d . -f2
          + old_major_digit=6
          ++ cut -d . -f1
          + new_branch_digit=11
          ++ cut -d . -f2
          + new_major_digit=7
          + (( old_branch_digit == 10 ))
          + old_major_digit_incr=7
          + (( old_major_digit_incr == new_major_digit ))
          + diff -u /tmp/version.old /tmp/version.new
          --- /tmp/version.old	2025-02-11 20:09:13.036386067 +0000
          +++ /tmp/version.new	2025-02-11 20:09:35.889329108 +0000
          @@ -1 +1 @@
          -11.6.2
          +11.7.2
          

          rvarzaru Varzaru Razvan-Liviu added a comment - Now, given that we don't have 11.0 builds anymore, I can check the logic for a major upgrade in the 11.x series, which does look sane. https://buildbot.mariadb.org/#/builders/443/builds/2001/steps/3/logs/stdio + check_upgraded_versions + for file in /tmp/version.old /tmp/version. new + [[ -f /tmp/version.old ]] + for file in /tmp/version.old /tmp/version. new + [[ -f /tmp/version. new ]] + [[ major == \m\a\j\o\r ]] ++ cut -d . -f1 + old_branch_digit= 11 ++ cut -d . -f2 + old_major_digit= 6 ++ cut -d . -f1 + new_branch_digit= 11 ++ cut -d . -f2 + new_major_digit= 7 + (( old_branch_digit == 10 )) + old_major_digit_incr= 7 + (( old_major_digit_incr == new_major_digit )) + diff -u /tmp/version.old /tmp/version. new --- /tmp/version.old 2025 - 02 - 11 20 : 09 : 13.036386067 + 0000 +++ /tmp/version. new 2025 - 02 - 11 20 : 09 : 35.889329108 + 0000 @@ - 1 + 1 @@ - 11.6 . 2 + 11.7 . 2
          danblack Daniel Black added a comment -

          A 10.11 update to 11.5 performing resulting in a error was incorrect, but seems resolved now.

          danblack Daniel Black added a comment - A 10.11 update to 11.5 performing resulting in a error was incorrect, but seems resolved now.

          People

            rvarzaru Varzaru Razvan-Liviu
            danblack Daniel Black
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: