Boxfuse 
Flyway updates the database from one version to the next using migrations.
Migrations can either be versioned or repeatable. Versioned migrations have a unique version and are applied exactly once. Repeatable migrations do not have a version. Instead they are (re-)applied every time their checksum changes.
Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed. Repeatable migrations are applied in the order of their description.
Both versioned and repeatable migrations can be written either in sql or in java and can consist of multiple statements.
Within a single migration, all statements are run within a single transaction.
To keep track of which migrations have already been applied when and by whom, Flyway adds a special bookkeeping table to your schema. This metadata table also tracks migration checksums and whether or not the migrations were successful.
Read more about this in our getting started guide on how Flyway works.
Migrations are either resolved or applied. Resolved migrations have been detected by Flyway's filesystem and classpath scanner. Initially they are pending. Once they are executed against the database, they become applied.
All statements of a migration are run within a single transaction.
Repeatable migrations whose checksum has changed since they are last applied are outdated until they are executed again.
When Flyway discovers an applied versioned migration with a version that is higher than the highest known version (this happens typically when a newer version of the software has migrated that schema), that migration is marked as future.