BC Break Report

Summary

I have a SF 4.4 app, originally created using the 'website-skeleton' composer package. As such, it does pull in orm-pack, which includes both doctrine and doctrine migrations.
The app's goal is to manage multiple databases, and as such it does not have a doctrine default connection set up.
In fact, it has no doctrine dbal connections defined at all (it sets up db connections on the fly when needed).
It also does not use doctrine migrations - even though it might in the future if the need arises...

Previous behaviour

The app worked fine.

Current behaviour

When running composer upgrade, doctrine migrations got bumped to 3.0.1. In the process, the Sf console command broke.
To fix that, I had to manually set the migrations_paths config in doctrine_migrations.yml.
However, as soon as I ran bin/console, I got an error:

The service "doctrine.migrations.dependency_factory" has a dependency on a non-existent service "doctrine.dbal.default_connection".

Questions

1. Is it still possible to have Migrations installed without defining a db connection? If so, how can it be achieved? Reading around other bug reports, it seems that defining a custom default entity manager might do the trick, but it does not seem trivial for this scenario...

2. Given all the 'magic' happening with Symfony Packs, Flex and whatnot, I was slightly surprised to see a simple composer update break the app. Did I miss running any command that would have updated the config files automatically for me? If not, how comes that the standard set of dependencies for SF 4.4 apps does allow the bc-break-inducing Migrations 3.0 package to creep in?