Make sure to load the upgrade script for the future 2.4

[jeltz]

We added an upgrade script for the future 2.4 release in commit 3481ee7 but we never actually bumped the version in the control file so the file was never loaded and therefore the tests were never updated to match dropping the pgsm_create_13_view() function.

Questions

• Should we make sure the upgrade script for the upcoming release is ran? I think so because otherwise we may have broken code in the repo.
• What should the upcoming unreleased version be named? 2.4, 2.4-dev, dev, something else?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.47%. Comparing base (12b2595) to head (e6cbdce).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #648   +/-   ##
=======================================
  Coverage   86.47%   86.47%           
=======================================
  Files           3        3           
  Lines        1346     1346           
  Branches      217      217           
=======================================
  Hits         1164     1164           
  Misses         86       86           
  Partials       96       96           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AndersAstrand]

Here is one idea:

If there is ongoing SQL changes in main, we change the version in the control file to "development" and make upgrade scripts and whatnot for that version. This will then have to be renamed and such in the release branch.

This seems less prone to mistakes to me than trying to predict what the next release version will be named.

[jeltz]

Yeah, my idea was basically call the next version for "development" or "dev".