Hi everybody,
some of you may have noticed that zend-di changed a lot with version 3.0. One of it’s major changes is an easy integration with Zend ServiceManager which makes zend-servicemanager-di obsolete.
However, users of zend-servicemanager-di may be challenged when upgrading to zend-di version 3, because they have to remove zend-servicemanager-di completely. I opened https://github.com/zendframework/zend-di/pull/35 stating details.
To improve the adoption of v3 I’m planning to create a PR against zend-servicemanager-di for a new major/minor version, that deprecates itself and allowing users to migrate more gracefully. I think it would improve this compontent’s quality a lot. But before investing any work here I’d like to hear your point of view and if there are any objections.
@tux-rampage Creating another minor release for zend-servicemanager-di is very good idea. If you can deprecate there some methods, and add notices what should be used instead it should help with migration to zend-di and dropping zend-servicemanager-di at all.
Another major release could only complicate things because then folks will have to update to ‘deprecated’ zend-servicemanager-di v3 to move next to zend-di, so it seems to be more complicated.
Always you can also add some tools to help with migration - for example in expressive we have zend-expressive-tooling with some tools which are useful on migration (first we used them on v1->v2 migration and now we have some for v2->v3 migration). I would also recommend to have a look on @matthew PR in stratigility: https://github.com/zendframework/zend-stratigility/pull/140 where he provides backports and deprecations in 2.X release for upcoming 3.0 version. If we could have similar approach in zend-servicemanager-di 1.X it would be great!
for a new minor version containing:
-
@deprecated annotations
-
E_USER_DEPRECATED error triggers with descriptive advice on how to update/migrate
- migration documentation
- and optionally, tooling (if there’s meaningful tooling to create)
As @michalbundyra notes, a new minor version makes more sense here, as users will typically get that on a composer update without needing to make changes to existing constraints.
Thanks a lot for your feedback.
In general im in favour of a minor release as well (you stated the reasons):
What we should take into account ist that with a minor verision the update would cause zend-di 3 to be installed if there is no version constraint in the user’s composer.json for zend-di itself, since the requirement for zend-di would change from ^2.0 to 2.0 | 3.0.
Supporting zend-di 2.x and 3.x in zend-servicemanager-di is a bit challanging but doable (It might result in some nasty workarond though). What bother’s me more: zend-di 3 removes aware and method injections, it will fall on people’s feet when they will then update servicemanager-di. The only solution then is to document this and suggest to pin zend-di to version 2.x. I don’t know how many will actually hit this and if it’s even worth bothering.
Otherwise this:
- @deprecated annotations
- E_USER_DEPRECATED error triggers with descriptive advice on how to update/migrate
- migration documentation
Plus:
- Making zendservicemanager-di work with version 3.0 (Call it backporting)
Was what I had in mind.
I’m not sure if tooling is applicable, if so it might be added. Maybe in a second step, depending on my available time or if somebody is willing to support.
You can mark zend-servicemanager-di as conflicts with zend-di v3. I’d primarily note that the component is deprecated, and trigger deprecation errors whenever functionality in it is invoked, directing folks to migration documentation.
I See. What I wanted to do, is to make it work with v 3.0 of zend-di as well, or offer a additional version of it that does …