# RFC: Changes to zend-servicemanager-di

**URL:** <https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441>\
**Category:** Contributors\
**Created:** [January 22, 2018, 11:47am UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441 "2018-01-22T11:47:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![tux-rampage](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/tux-rampage/32/237_2.png) [@tux-rampage](https://discourse.laminas.dev/u/tux-rampage)\
**Post date:** [January 22, 2018, 11:47am UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/1 "2018-01-22T11:47:10Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![michalbundyra](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/michalbundyra/32/185_2.png) [@michalbundyra](https://discourse.laminas.dev/u/michalbundyra)\
**Post date:** [January 24, 2018, 12:22pm UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/2 "2018-01-24T12:22:53Z")

</div>

@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](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!

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [January 24, 2018, 5:19pm UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/3 "2018-01-24T17:19:16Z")

</div>

👍 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.

---

<div class="post-metadata">

**Author:** ![tux-rampage](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/tux-rampage/32/237_2.png) [@tux-rampage](https://discourse.laminas.dev/u/tux-rampage)\
**Post date:** [January 25, 2018, 2:42pm UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/4 "2018-01-25T14:42:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![matthew](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/matthew/32/14_2.png) [@matthew](https://discourse.laminas.dev/u/matthew)\
**Post date:** [January 25, 2018, 2:47pm UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/5 "2018-01-25T14:47:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tux-rampage](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/tux-rampage/32/237_2.png) [@tux-rampage](https://discourse.laminas.dev/u/tux-rampage)\
**Post date:** [January 25, 2018, 2:53pm UTC](https://discourse.laminas.dev/t/rfc-changes-to-zend-servicemanager-di/441/6 "2018-01-25T14:53:44Z")

</div>

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 …