Proposal: backport migration

[guillep2k]

I've created a pattern to support backporting certain migrations. As an example, I've backported #10617.

Important: This PR is not pointing to master but release/v1.11

I've labeled this PR kind/proposal for the system and kind/bug for the migration I've included.

[lunny]

But then the same migrations may be executed twice?

[guillep2k]

But then the same migrations may be executed twice?

Yes, that's a requisite. Only migrations that can be executed twice, like the one backported here. I've wrote it down right before the declaration, just in case:

// Backports are only applied after latest version in 'migrations'.
// This list must be **empty** in master, but can contain items in release branches.
// Backported migrations must conform to the following criteria:
//    * The function must support being executed multiple times (e.g. when updating to the next
//      minor revision and when the actual migration is executed again on the next major upgrade).
//    * The function must not rely on data structures that might not be present in the branch
//      it is backported to, unless its safe that it will add the column itself.

[6543]

Not bad but the 117.1.go is a weared naming concept. Why not name bakports like bachport_<number>.go?

[guillep2k]

Not bad but the 117.1.go is a weared naming concept. Why not name bakports like bachport_<number>.go?

I wanted it to follow the version/subversion number in the version table.

[techknowlogick]

We could also use a tool such as xormigrate which keeps track of all the migrations that are run, instead of just the latest, and would be able to handle the case of backporting a migration.