Closed wbloszyk closed 4 years ago
Maybe we should merge this after all code in our packages is migrated?
@greg0ire Please read #741 one more time. This way will be much better. I have all this PRs prepared. Just check it and after all release. We can drop CoreBundle in Sonata 3. After this change we make https://github.com/sonata-project/dev-kit/issues/697. Next will be https://github.com/sonata-project/SonataBlockBundle/issues/700. Then we can focus how use 0.x extensions in Sonata 4.
Maybe we should merge this after all code in our packages is migrated?
What I mean is maybe we should add deprecations only after sonata-project/dev-kit#697 is done. That way end users do not get deprecations they cannot fix.
Maybe we should merge this after all code in our packages is migrated?
What I mean is maybe we should add deprecations only after sonata-project/dev-kit#697 is done. That way end users do not get deprecations they cannot fix.
I understand what you mean. Anyway we cant done sonata-project/dev-kit#697 before #741. We need stable 0.x extensions and this is the easiest way to do it. We can add this deprecations after both issues but for now CoreBundle also have some deprecations which user couldn't fix. I think we should not avoid add new deprecations if in this way we can resolve this BIG CORE problem.
It's it's much harder to add the deprecations later, don't do it. It's better DX but I'd rather have this done than discourage you :sweat_smile:
Subject
I am targeting this branch, because it is BC.
Part of #741
Changelog