Proposal: Add Support for Semantic Versioning in Migrations

[xoac]

I believe it would be beneficial to support semantic versioning (semver) instead of relying solely on numeric versions. Using semver in migration names allows for additional context, indicating the significance of the next migration.

This could be implemented as an optional feature, providing flexibility while maintaining compatibility with the existing numbering system.

Would love to hear your thoughts on this!

[jxs]

Hi there, and thanks for the interest!
Can you elaborate on what kind of additional context would you like to add?
Can you provide an example or link any other migration tool that implements this feature?
Thanks

[xoac]

@jxs some motivation can be found here: https://www.red-gate.com/hub/university/learning-pathways/database-devops-learning-pathway/database-versioning-source-control/level-0/the-what-why-and-how-of-database-versioning-with-flyway

Consider this example: If your database's current version is V1.5.7 and you're about to apply a migration labeled V2.0.0, the jump in the major version number (from 1 to 2) immediately signals a potential breaking change. This is just one example semver gives much more.

[Nerglej]

To add to this, Flyway does something like that in the form of e.g. V1_0__create_some_table.sql or V3_2__modify_an_old_table.sql.

This also helps ordering scripts when developing, so it's easier to name them and where to add them. Imagine a new project with 20 migration files, V1-V20. Before going into the first production release, they need to add a table early on in database schema, let's say V3. Now you've got to rename all files all the way up to V21.

I know this is a pretty specific situation, but the idea is still there. You would be able to kinda version features, so everything in the start, related to lets say a product table could be under V1_1_0__create_product_table.sql and some other related table could be under V1_1_1__some_related_product_table.sql. So everything in version 1.1 is related to the product tables. Same applies to then modifying product tables some versions later: V8_4_0__add_new_column_to_product_table.sql and V8_4_1__alter_another_table_which_references_new_column.sql. Now a developer knows that these sql-scripts depend on each other in a more specific way. Then a V8_7_x would indicate that it's a script in the current development cycle, but another feature that doesn't necessarily depend on something in V8_x.

Now, while developing, it's easier to either add V8_3_x__something.sql if that's needed, before a production release, since now all V8_4's needs to be V8_5's and so on. All the small almost one-line sql-scripts is not as hard to modify for a developer, while it's still easy to get an overview by looking.

Please discuss my arguments, because I can still see why you would not need this and how a single version number can be better in some cases.