[Breefield]

Prior to my joining the team, our homemade migration tool used sequential versioning numbers for filenames, i.e. 001_migration_name.sql, 002_migration_name.sql.

As our team was grew, it was very common to publish a PR, and right before merging realizing you had a conflict with someone else who'd merged to master ahead of you, using your sequence number.

I made a small change to the system, replacing the sequence numbers with unix timestamps and added some previously non-existant tests to cover the migration utility.

Unfortunately the subsequent PR took weeks to be approved by the team/eng leads because there was a lot of hand-wringing about this change. Once it was merged though we never thought about it again, it worked exactly as I'd hoped and nobody ever had to make a final "fix migration name" commit again.

[eloff]

I used to lose so much time to that, imagine coupling it with multi week code reviews (another process that needed to be fixed). I'm actually building a migration tool as part of a web framework (free time project). I'm going to "steal" this idea of yours if you don't mind.

To play devil's advocate, probably part of the reason for the sequence number approach is so if that PR that merged ahead of you conflicts with your migration you're more likely to notice if you have to rename it. I don't think that's particularly common though, and the problem should surface when the CI build runs your migrations prior to permitting the merge to master ( a good CI setup requires you to pull master into your PR if it's out of date, which ensures the combination didn't break things.)

[ravedave5]

Funny my team had the same issue and I did something similar, except I went with one file per release and they would merge changes like any other code file.