Reconsider MySQL 5.7 support in Community until EOL, disable Teams edition preview in docker

Which version and edition of Flyway are you using?

7.15/8.0.0

If this is not the latest version, can you reproduce the issue with the latest one as well? (Many bugs are fixed in newer releases and upgrading will often resolve the issue)

Yes, see below.

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

command line (docker image)

Which database are you using? (Type & version)

MySQL 5.7.35

Which operating system are you using?

kubernetes

What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)

Ran a migration against MySQL 5.7

What did you expect to see?

A successful migration

What did you see instead?

Part 1:

The 8.0.0 community version removed compatibility with MySQL 5.7, despite it being supported by Oracle for an additional ~2 years. This is a pretty unfortunate decision, since you still have to go through the effort to support it in code for the Teams edition and it’s not EOL yet. I was introduced to flyway in a hobbyist project that I’m working on via another contributor, and I have reasonably enjoyed using it but changes like this degrade my opinion of the product significantly. I have pinned to 7.15 for now, but …

Part 2:

I backed out to 7.15, where I then saw:

Running kubectl logs -f -l app=migration
WARNING: This version of Flyway is out of date. Upgrade to Flyway 8.0.0: https://rd.gt/3rXiSlV

Flyway Teams Edition 7.15.0 by Redgate
Database: jdbc:mysql://mysql:3306/game (MySQL 5.7)
----------------------------------------
Flyway Teams features are enabled by default for the next 27 days. Learn more at https://rd.gt/3A4IWym
----------------------------------------

I was very surprised to see that I was temporarily granted Teams features. I am now setting the edition to Community vs. Teams via environment variable in my yaml definition for the migration job, but I’m glad I looked at the logs: I wouldn’t want to accidentally create automation that relies on features that will be removed. This should not be the default to mysteriously break later if you’re not paying attention. Please consider defaulting to Community edition and requiring manual intervention to upgrade to Team edition in docker containers which will be primarily used by automation.

[Homicydal]

@DoodleBobBuffPants wouldn’t a simple solution that would be “safe” and not have much impact on users be to just error if users try to use features (like DBMS support) that require Teams edition, and let the user provide a flag or environment variable that enables Teams with a grace period? Then it would truly be “opt-in” and users couldn’t inadvertently use flags that are Teams features. This feels like it is even more user-friendly than the current paradigm and is very quick to resolve if you’re already a Teams license holder.

[DoodleBobBuffPants]

By ‘opt-in’ we mean that running the Teams edition will yield the same results as running the Community edition with no change in configuration

However when it comes to database support you are right, databases only supported in Teams won’t continue to work in Community