-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump DBAL 4 min version to 4.2.0 #234
Comments
This only concerns our generated types with SQL
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 |
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. |
Alright, makes sense |
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) |
Indeed, conflict is the way to go 👍🏻 |
There was an issue with infinite migrations being generated when using DBAL 4 - doctrine/migrations#1441
After a lot of discussion, there came a fix from doctrine team which works with MySQL ENUMs - doctrine/dbal#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?
The text was updated successfully, but these errors were encountered: