Bump DBAL 4 min version to 4.2.0

[michnovka]

There was an issue with infinite migrations being generated when using DBAL 4 - https://github.com/doctrine/migrations/issues/1441

After a lot of discussion, there came a fix from doctrine team which works with MySQL ENUMs - https://github.com/doctrine/dbal/pull/6536

I would argue that this is a required min. version of DBAL in order for the plugin to work without issues.

Shall we bump dependency?

[ogizanagi]

This only concerns our generated types with SQL enum(…) declaration, right ? (i.e https://github.com/Elao/PhpEnums/blob/503a7fbe4e2ec3da23b83a4e2fbc45f373677919/src/Bridge/Doctrine/DBAL/Types/AbstractEnumSQLDeclarationType.php#L23)

Bumping would make sense, but might be annoying for those not using this feature. I'm wondering if triggering a deprecation depending on the installed dbal version from the AbstractEnumSQLDeclarationType might be a better option? WDYT?

[michnovka]

I disagree this is an inconvenience. If 4.0 is used by the project, then 4.2 has no breaking changes, thats given with Doctrine.

As of now, the DBAL4 integration is broken. It does not work with migrations. The DBAL version 4.2 fixes this

I see no reason to "deprecate" < 4.2.0 DBAL, as its just broken now. On the other hand forcing dependency to 4.2.0 makes sure that the Doctrine DBAL integration is functional.

We can of course keep 3.x support, so I don't se how this would affect most users.

[ogizanagi]

Alright, makes sense

[michnovka]

hmm, we actually do not require DBAL at all. We have it in require-dev only.

So either we keep it as is, or we can add conflict for DBAL 4.0-4.2 (I would do that, as really it IS broken with these versions)

[ogizanagi]

Indeed, conflict is the way to go 👍🏻