Flyway 7 Breaking Changes Announcements

Flyway 7 is released!

Flyway 7 has now been released. You can find the official list of the breaking changes in the release notes: https://flywaydb.org/documentation/releaseNotes#7.0.0.

The text below is possibly out of date now. I’ll keep it for posterity. Refer to the release notes for the complete information.

---

Flyway 7 is due roughly in the summer of this year. We plan to make the following breaking changes on the first version 7 release:

Platform support

• Some database versions will reach their 5 year support cut-off for Community and Pro editions
  • See https://github.com/flyway/flyway/issues/2466
• Flyway will no longer support Java 7. Instead we’ll move to Java 8.
  • See https://github.com/flyway/flyway/issues/2598

Breaking changes

• Non-existent locations in flyway.locations will produce errors instead of warnings
• Use of dots (.) as path separators in flyway.locations will be deprecated and produce an error when used
• MigrationType.SPRING_JDBC and MigrationType.UNDO_SPRING_JDBC will be removed
  • Use MigrationType.JDBC and MigrationType.UNDO_JDBC instead
• In order to support JSON output we’ll need to change the return types of public methods in the Flyway class
  • See https://github.com/flyway/flyway/issues/2507
• Placeholder names will become case insensitive
  • See https://github.com/flyway/flyway/pull/2808
• Flyway command line will no longer load config files from standard input, but instead require a - to be passed to the configFiles argument
  • See https://github.com/flyway/flyway/issues/2859

Comments and questions are welcome. This post will be updated with more changes in the run up to version 7.

[MikielAgutu]

@cowwoc Internally, paths that began with classpath: have dots replaced with slashes. So a location like this:

classpath:path.to.my.migration

Is converted internally to:

classpath:path/to/my/migration

Such paths will produce an error in V7.

The code is in Location.java.

[stellingsimon]

Thanks for announcing these changes early on and allowing us to comment.

Non-existent locations in flyway.locations will produce errors instead of warnings

As long as these locations may be empty without Flyway considering that to be an error, this is a great idea. I lost countless hours to debugging Flyway only to find out I had a typo in one of the locations.

Zooming out a little, though, it feels like a breach with the concept of “dynamic discovery” currently used:

As it is now, it feels to me like Flyway is trying to be “smart” with information about the migrations being decentralized, so locations was always interpreted as “look in these places and figure out what to do”.

(Many disliked this “smartness”, including me, see #2698, #2541, #2610, #2647, #2683, …)

In contrast, it could be “dumb”, with information about the migrations being centralized, so instead of locations I provide a MigrationManifest to Flyway, telling it exactly what to do in which order with which options. In this world, it better report errors at the first ambiguity.

By being strict on “locations” (which is one of the few centralized configuration points), Flyway somewhat limits the ways I interact with it. For example, we currently have just one Flyway configuration for both production and setups with a test fixture:

locations=classpath:migrations/prod,classpath:migrations/testfixture

Since we make sure not to include demo-data in a production setup, there is no need to have two different Flyway configurations. So with Flyway 7.0, we’ll either have to make structural changes to our deployment setup. Providing an empty classpath:migrations/textfixture in production JARs just to make Flyway happy looks tempting but would ultimately lead to people accidentally placing files there.

In conclusion, I’d like the following most:

• a “smart” mode with a lenient location configuration parameter, where Flyway is expected to be “smart”, trying its best but not failing.
• a “dumb” mode with a non-lenient MigrationManifest configuration parameter, where Flyway is given precise instructions and thus failing as soon as it detects those instructions to be nonsensical.

Lacking that, I’d wish for a configuration option treatMissingLocationAsError with a default value of true.