Delivering hot fixes using Flyway

Let's consider the What is the best strategy for dealing with hot fixes? question from the Flyway FAQ section. In this question:

1. Application version 7 (and DB version 7) is deployed in production
2. Work starts on app version 8
3. DB version 8 is developed and deployed in the accepta开发者_运维知识库nce test environment
4. Bug is identified in production
5. DB version 7.1 is developed and must be acceptance-tested

When flyway:migrate will be invoked against the acceptance test environment, it will notice that v8 has already been executed and so that there is no need to execute v7.1.

On one side it makes sense since v7.1 might not be compatible with v8, and it is not up to Flyway to analyze this. Fail-fast is entirely understandable.

On the other side, the only way to deploy v7.1 to the acceptance test environment is to clean the database and run flyway:migrate with target = v7.1, thereby discarding data that might have had its use.

Is there a feature I'm not aware of that handles this case or is clean + migrate.target=v7.1 the only option?

More than a different feature, it's about a different process.

If you do wish to keep your data in your acceptance environment, I would recommend shipping v8 of the database with the hotfix and the actual change can then be v8.1. The features of the v8 schema might remain unused until the corresponding code gets deployed. In most cases however, this causes no harm.