Disable doctrine/dbal dev job

[greg0ire]

Porting prep work to 2.12.x would mean porting fixes for something that
is not actually impacting the end user.

[morozov]

I see that ORM 2.12.x supports DBAL ^3.2:

orm/composer.json

Line 29 in 67d82cd

"doctrine/dbal": "^2.13.1 || ^3.2",

What will happen after the DBAL 3.4.0 release?

[greg0ire]

Didn't think of that... I think maybe we should release ORM 2.13 first.
🤔 ah but ORM 2.13 requires DBAL 3.4 … maybe the solution is to add use the conflicts section of the DBAL's composer.json

[morozov]

maybe the solution is to add use the conflicts section of the DBAL's

The DBAL doesn't depend on the ORM nor does it provide any of the APIs provided by the ORM, so it cannot conflict with it.

In general, I don't think the introduction of a conflict is the best idea because:

1. It would imply that they are incompatible and thereby the DBAL has introduced a BC break which it didn't.
2. Users would have to update both the DBAL and the ORM at the same time which should be avoided, if possible.

A better solution might be to:

1. Remove the tests that were removed in 2.13.x.
2. For the rest of failing tests that check if ($platform->supportsForeignKeyConstraints()) also check if (!$platform instanceof SqlitePlatform).

[derrabus]

In general, I don't think the introduction of a conflict is the best idea because:

1. It would imply that they are incompatible and thereby the DBAL has introduced a BC break which it didn't.

2. Users would have to update both the DBAL and the ORM at the same time which should be avoided, if possible.

For the same reasons, I'd like to avoid removing the @dev workflow. The ORM's functional tests are a pretty good indicator for potential BC breaks inside the DBAL. If our tests are broken, we should rather fix the tests.