Set SemverCompatible to false for Conan packages (#21275)

[KN4CK3R]

Backport of #21275

[wxiaoguang]

Backported migration will break the new releases.

[KN4CK3R]

You are right, how to handle that?

[wxiaoguang]

No idea .... there was an old PR for backport migration (#10625) but no progress. I wasn't a member at that time.

[silverwind]

So in essence, the migration system can not detect whether a certain migration, identified by a string, has already ran and skip it? I think the numbering scheme would have to be dropped to make it more smart then.

[wxiaoguang]

So in essence, the migration system can not detect whether a certain migration, identified by a string, has already ran and skip it? I think the numbering scheme would have to be dropped to make it more smart then.

No at the moment. The Gitea's migration system is quite tricky and needs to be improved IMO.

For this backport, maybe the migration can be dropped, and tell users to run a SQL manually if they encounter the bug (very few), or provide temporary doctor command (although I prefer to avoid too many doctor commands).

[KN4CK3R]

So in essence, the migration system can not detect whether a certain migration, identified by a string, has already ran and skip it? I think the numbering scheme would have to be dropped to make it more smart then.

The migration could be run multiple times in this case but yes, the "index" 224 would be marked as "already run" and the real 224 from Gitea 1.18 would be skipped.

[noerw]

Not a solution for this PR, but something to keep in mind for the 1.19 dev cycle:
Maybe the simplest change would be to reserve a couple (10?) migration IDs when starting a new major release, so there is room for migrations in point releases. This would still require that backported migrations are idempotent (as they potentially would be run twice), but at least the ambiguous-migration-ID-problem would be solved. I guess the question is how to best make these reservations a part of the new-release-cycle-process, so it doesn't slip when the first migration of the new cycle is added.

[silverwind]

For future improvement to the migration system, I would suggest using a set of unique strings that identify migrations, ideally inserted into a separate table once ran. That way, all the number collision problems go away as well.

Thought generally I would expect the ORM to handle migrations transparently and in simple cases like column addition or type changes, automatically.