Major means breakage possible, minor means safe. For twenty years a MySQL version number carried that promise, and you could plan by reading it. With the move to calendar-style releases the number tells you one thing: when it was built. The promise moved elsewhere, and you have to know where to look.
The signals now are the channel and the dates. Is this an LTS or an innovation release. When does support end. What do the compatibility notes actually say, because “no major version” does not mean “no behavior change”. Optimizer changes ship in any release. Your query plans do not read version numbers.
This changes process more than SQL. A support matrix in the repository: which server versions we run, which we test in CI, which we are leaving. A staging database that gets the new release first, with a fixed set of regression queries instead of hope. And expectations for the managed provider written down, because they will move you on their schedule if you have none of your own.
I ended up with a simple policy. Production follows LTS. Once or twice a year, run the test suite and the regression queries against the current release, to see the future early. And put the next upgrade in the calendar. Versions live there now anyway.
I still read the number first. Old habit. Then I go and find the date.