-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Remove internal flag from TypeRegistry #4491
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API that should not be considered stable is stable? I don't know about the background why it wasn't considered stable though, but it seems that prophecy didn't come true.
As far as I understand from #3354, If the plan to replace |
This class is almost 2 years old and never received BC breaking change. We need to rely on its API so we can build DI integration in DoctrineBundle
cbb669b
to
256225d
Compare
To be able to register instance of the classes. Type class is doing
I think it would, but what work and what timeframe are we talking? I thought there was some blocker or unknowns if nothing was being done about this plan further, even though pieces were put in place. If this is only about replacing |
Internal is not an antonym of stable.
I don't think anybody but @Majkl578 knows. I'd expect the type registry to be a dependency of the connection. Otherwise, it's not much better than the current static class. |
Summary
This class is almost 2 years old and never received BC breaking change. We need to rely on its API so we can build DI integration in DoctrineBundle
I've chosen 2.12 because since there are no changes here between 2.12 and higher, it doesn't matter, unless we intend to do BC break in this class in 2.x but not 3.x (super unlikely). But it does matter for SA analysis for people still using DBAL 2.x.
Related: #2841, doctrine/DoctrineBundle#1246