Won't this require a (breaking) runtime change too?

This isn’t part of the runtime, but part of the compiler which isn’t stable.

Right, but SqlSchema.version is derived from this, isn't it? And also the values used for SqlSchema.migrate().

https://github.com/cashapp/sqldelight/blob/16526c3ad7d3d38e5e76321ccd04bcff91302f3e/sqldelight-compiler/src/main/kotlin/app/cash/sqldelight/core/compiler/DatabaseGenerator.kt#L240

Ah, you mean behavior, I thought about api only.
Yes, this will change the current behavior, but the current behavior is undefined. If we find a numerical value in the name, we try to parse this value to Int. If this fails, we use 0 as fallback as migration version, which will be overridden in an non deterministic way by another migration version with 0 too.

generated code breakages are okay, since you cant have a published library that depends on that API

Will rebase once a new sql-psi release is out.

Should we also change it upstream in sqliter to be a Long? https://github.com/touchlab/SQLiter/blob/a5a532b012cd84d706d143938660094b87b2dfcc/sqliter-driver/src/nativeCommonMain/kotlin/co/touchlab/sqliter/DatabaseConfiguration.kt

On Android you'd be able to use Long but on native it would just crash:

https://github.com/cashapp/sqldelight/blob/da0d4574600ba78555dac5ae72f0d2a842751482/drivers/native-driver/src/nativeMain/kotlin/app/cash/sqldelight/driver/native/NativeSqlDatabase.kt#L259

What do you mean with Android? The android driver does not support Long too and it also crashes.

So we only changed it for non android/ios consumers?

The change affects all targets, but from my view I would use a long version, eg version based on a timestamp, for backend systems. On mobile, you could easily use the build/release number as migration number, which is rarely bigger than Int.max.

Also, to get a crash, you need to change your versioning after using sqldelight 2.0.0-rc02. The old behaviour is still working.