Reputation: 337
suppose I have 2 branches:
Develop with migrations:
V1_change1
V2_change2
V3_change3
V4_change4
V5_change5
Master with migrations (deployed on production):
V1_change1
V2_change2
Now I'm doing hotfix on production, adding new migration V3_sth_completely_different, so the situation is:
Develop with migrations:
V1_change1
V2_change2
V3_change3
V4_change4
V5_change5
Master with migrations (deployed on production):
V1_change1
V2_change2
V3_sth_completely_different
Next, I'm merging changes deployed to master to develop (I'm using support branch to do all this stuff, but it's not important at the moment).
I want to have consistent DB version (V1, V2, V3 ...) so I don't want to use timestamps. Because there's no rollback feature, I have to:
Finally I have:
Develop with migrations:
V1_change1
V2_change2
V3_sth_completely_different
V4_change4
V5_change5
V6_change3
Master with migrations (deployed on production):
V1_change1
V2_change2
V3_sth_completely_different
========================================================================
Upvotes: 6
Views: 2380
Reputation: 894
Yes, I think you're overthinking things.
Why is "simple version numbers" a requirement for you? As @Hamish Carpenter said, Flyway has this usage case covered with using dotted version numbers. This way, you don't have to do all of the cumbersome (as you say) steps that will throw off all of the checksums designed to maintain schema integrity.
Upvotes: 1
Reputation: 851
The Flyway FAQ covers this under What is the best strategy for dealing with hot fixes? However it uses x.y version numbers which you wish to avoid. An alternative to this is to multiply the version numbers by 10 or 100 and use the inbetween integers to represent a hotfix. Using 10 gives you 9 hotfixes or 100 gives you 99.
Upvotes: 4