symfony/dsn is a requirement to keep BC. But in sf 4.0 in could be a suggesiton.

What is the upgrade path to deprecate a requirement?

We have none: just read UPRGRADE files, that's what we did in the past

missing "use" statement to shorten the FQCN here.

Just asking: if in the catch we just throw an exception ... would it better to remove the catch entirely to throw the original and more specific DsnInvalidArgumentException ?

👍 for throwing DsnInvalidArgumentException, as that already is a framework specific exception

Wouldn't it be a BC break?

it would yes, so the rethrow is required actually

Should this switch logic be moved to the Dsn component itself to avoid duplicating it in every component using it? Something like this:

// Before
switch ($type) {
    case ConnectionFactory::TYPE_MEMCACHED:
        return MemcachedConnectionFactory::createConnection($dsn, $options);
    case ConnectionFactory::TYPE_REDIS:
        return RedisConnectionFactory::createConnection($dsn, $options);
}

// After
return ConnectionFactory($type, $dsn, $options);

such methods already exists in the Dsn component => ConnectionFactory::create($dsn, $options).

But this methods may return anything (\Pdo, \Ldap, etc...). By using directly the Dsn factory, we are changing the behavior of this method (which previously throws an exception when the DSN wasn't neither redis://, neither memcached://)

I still don't understand this ... but if Nicolas and you say it's correct, then I'm sure it's correct 😄

Given the following userland app code

try {
   $c = AbstractAdapter::createConnection('mysql://localhost');
  echo 'got a '.get_class($c);
} catch (InvalidArgumentException $e) {
  echo 'expected faillure';
}

using the switch => expected faillure
using Dsn\ConnectionFactory::create => got a \Pdo

It sounds like a BC Break, but IMO i'm also fine to use whats you suggest and saying "we are not responsible of the output of this method if you enter weird things"