Flyway is a very nice tool to automate database updates (also called migrations). However, as of version 1.7 it relies on a completely linear sequence of migrations. This assumption is immediately void if you have a production system for which you have to deliver fixes while you are already developing new stuff. The FAQ argues correctly that this is a non-issue for the production system itself, but if you have development and/or QA-systems that already on the development branch, you need to run migrations from the fixes for the production version out of band.
A solution that would allow this is pending with Issue 138, but is not done yet. Since this is pretty much a deadly problem: are there any clever workarounds if I want to use it right now?
The problem is obsolete since Flyway version 2.0: if you set the outOfOrder flag then flyway will also execute migrations with earlier version numbers that have not been applied yet. You need however to make sure that such out of band migrations can be applied in any order to the later migrations, or you will run into serious trouble.
With Flyway-1.7 you could make the following workaround. If you have a development and a production branch, you could have separate instances of flyway including separate metadata tables (say, SCHEMA_HISTORY and SCHEMA_HISTORY_DEV) for the production and the development branch. On the production server there is only the SCHEMA_HISTORY and you work as usual; for the development server you have both, and each time you run flyway you first run it on the production branch sqls with the SCHEMA_HISTORY and then on the development branch sqls with the SCHEMA_HISTORY_DEV.
When you switch branches you have to merge the SCHEMA_HISTORY_DEV into SCHEMA_HISTORY. (You need to exclude the initial revision and reset the CURRENT_VERSION on SCHEMA_HISTORY.) And when flyway-1.8 comes out, you do this merge and throw SCHEMA_HISTORY_DEV away.