Add backport migration support

[yp05327]

Changes:
Use BackportVersion table to store migrated versions in newer versions.
When users upgrade gitea version, we can skip the migrations recorded in BackportVersion table.

I have no idea about testing now.
So it may have bugs now.

[wxiaoguang]

That's really a difficult part in Gitea. 👍

There are also some related issues/PRs, not sure whether they would help or not.

• NoOp DB Migrations to allow for DB backports #23078
• Proposal: backport migration #10625
• Proposal: use uuid instead of numbers to identify migration steps #8613

Do you have a design document for how to use this Backport Migration mechanism (for various different cases)?

---

Update: quote from lunny in #23078:

Assume users are in v1.19.3 which will add a new column, but for v1.20.0 has no migration for this column but v1.20.3 has, when user upgrade from v1.19.3 to v1.20.0 not v1.20.3, it will encounter problems.

[yp05327]

Update: quote from lunny in #23078:

Assume users are in v1.19.3 which will add a new column, but for v1.20.0 has no migration for this column but v1.20.3 has, when user upgrade from v1.19.3 to v1.20.0 not v1.20.3, it will encounter problems.

I didn't notice this problem.
But it is hard to handle this, as we have no restore processes.
So add restore processes or forcibly upgrade to 1.20.3?

[wxiaoguang]

I guess we have similar idea #23078 (comment) and #23078 (comment)

I am not working on this problem, so at the moment I can't help much. I guess it would be better to have a design document first before coding, because this problem is more complex than it looks.

[yp05327]

I'm fixing org/user projects bugs, and there are some db migration in the fix.
If we only backport the code but not backport migrations, it will cause new bugs in old version.
Fix bugs and bring new bugs (=no fixes) :(
So I think we need to fix this problem ASAP.
You are right. We need to discuss the design first.