Skip to content
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

Closed
michnovka opened this issue Oct 10, 2024 · 5 comments · Fixed by #235
Closed

Bump DBAL 4 min version to 4.2.0 #234

michnovka opened this issue Oct 10, 2024 · 5 comments · Fixed by #235

Comments

@michnovka
Copy link
Contributor

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?

@ogizanagi
Copy link
Member

ogizanagi commented Oct 10, 2024

This only concerns our generated types with SQL enum(…) declaration, right ? (i.e

abstract class AbstractEnumSQLDeclarationType extends AbstractEnumType
)

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
Copy link
Contributor Author

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
Copy link
Member

Alright, makes sense

@michnovka
Copy link
Contributor Author

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
Copy link
Member

Indeed, conflict is the way to go 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants