As a user I'm tired of having to do upgrades manually, this is a possible way to get upgrades automated in 5.x.

We need something like:

• To extend the SPI Persistence interface and Repository with a method to get database version:
  • (int) version()
• To extend Repository or a new system information api with version() method which returns the code version as generated by either build or some internal version number*
• To extend SPI Persistence, Repository and Bundles that need to handle migrations with:
  • upgrade( $fromVersion, $toVersion )
  • downgrade( $fromVersion, $toVersion )
    • In the case of persistence, $fromVersion always needs to be the same as returned by version()
• Add a ezpublish::upgrade console command

How it can work:
1. The command will check the Repository version and compare it to the system info version, if different offer user to upgrade or downgrade based on how they compare
2. emit the upgrade() / downgrade() command on all bundles that provides them
3. Core Bundle should have one, and pass it on to Repository which again calls SPI Persistence

It is important that persistence is first component called, as it is in a potential un stable state if versions between db and code does not match.

* how the version numbers should look like is a bit of a question, maybe an internal version number that can work across git, community and enterprise builds. But if ee version numbers are used, then all kinds of x.y.z versions where x is higher than 5 needs to be accepted by the functions. Additional gotcha: the version numbers might not make sense for other Bundles then the once from eZ, others will have their own version numbers.

Additional: It might be possible to setup composer to do such an upgrade as part of a post step after dependencies are updated as well, automating it further.