Managing hotfixes with Flyway

Question

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:

1. manually remove V3_change3, V4_change4, V5_change5 migrations from DB
2. delete rows in schema_version
3. change name V3_change3 to V6_change3 (if there is no conflict, if there is I have to change all following migrations)

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

The question is: Am I overdoing things?

How to manage hotfixes with Flyway preserving simple version numbers V1,V2,V3... ?

The process I'm using right now is very cumbersome.

========================================================================

Answer 1

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.

Answer 2

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.