Implement stricter MigrationFile versioning

[madisp]

Implements a stricter variant of MigrationFile versioning compared to the current "concatenate all digits in the name".

Version is extracted from a string of characters starting from the first digit (inclusive) and ending before the first non-digit non-separator (, :.-_T) character.

Technically a breaking change, although documentation only mentions 1.sqm, 2.sqm, etc...

Resolves #5730.

[madisp]

A few alternative even stricter approaches I considered which probably will break someone's workflow:

• only allow digits, e.g. 1.sqm and 001.sqm are valid, whereas v001.sqm or 001_create_foo.sqm are not
• only parse the digits at the beginning of the string, e.g. 001_create_foo.sqm is valid, but v001.sqm is not
• only parse digits with no separators, e.g. v001.sqm and 001_create_foo.sqm are valid but 000_001.sqm parses as 000

[JakeWharton]

We need some way to go back to the old mechanism. Maybe a Gradle property?

[madisp]

We need some way to go back to the old mechanism. Maybe a Gradle property?

I can take a stab at it, Gradle property sounds good. I'm not super well versed in how such data/config is passed around in the project though. I'm thinking of passing in an enum to MigrationFile ctor as the parsing strategy, would that be ok?

[kevincianfarini]

I'm the author of one of the projects linked in #5730, however I use flyway migrations instead of SQLDelight's built-in migrations. That being said I think the following proposal would still apply to my project.

We need some way to go back to the old mechanism. Maybe a Gradle property?

I think it'd be really nice if users of SQLDelight could specify a regex of what their migration filenames are supposed to look like in the Gradle plugin. The default value could match the current surprising behavior, but this allows others to be more strict. For example, the following would match filenames like V3__add_email_delivery_id.sqm and would fail for things like 1.sqm.

Regex("V(\d+)_(_[a-zA-Z]+)+.sqm")

I think the challenge in implementing something like this will be figuring out which part of the group represents the version number. I'm not familiar with developing Gradle plugins, but could a lambda be passed like the following?

sqldelight {
  database("...") {
    migrationFileRegex = Regex("...")
    migrationNumberExtractor { fileName: String -> /* map to an integer */ }
  }
}

[JakeWharton]

I definitely don't want to add a full regex or lambda support right now. As written this PR is a bug fix, not a new feature. The opt-out is a quick way for someone to revert to the old behavior while then renaming their files to conform to the new, stricter naming constraints.