Skip to content

Fix migrations on master after cherry-picking migration onto 3.11

Warren Gifford requested to merge fix-migrations into master

Created by: mrnugget

When cherry-picking a fix into the 3.11 branch I had to change the number of its migration from ...30 to ...28 in order to make the build pass (we need a consecutive sequence of numbers): https://github.com/sourcegraph/sourcegraph/commit/3c7ece1146cde1b8d202a3bc3c7aab939e8549f5

But, as @keegancsmith pointed out in this Slack thread, using the same number of different migrations in 3.11 and master (soon to be 3.12) will lead to customers skipping a migration when going from 3.11.1 to 3.12, since they already ran the migration with that number.

To fix that, this PR changes the migrations on master:

  • it puts the migration of the fix at the same number as it is in 3.11
  • it bumps the following two migrations
  • it makes every migration after the fix migration idempotent so it can be run multiple times without problems
  • it keeps a duplicate of the fix migration at the currently highest number

That means that users/developers that were on the latest migration before this PR here only run the new fix migration again. Others that were on a migration between the fix-migration in 3.11 and latest, run the now-idempotent migrations again.

Merge request reports