Closed tux-rampage closed 4 years ago
zend-servicemanager-di
is in 1.1.1
version - last release, so this PR should rather be with <2.0
, but anyway I don't like new major release of zend-servicemanager-di
just to deprecate the library and suggest using zend-di
, it should be done in minor release, IMHO
Since this is something that will take place in the zend-servicemanager-di module, which may take some time, I'd like to postpone this to a more future version and get some improvements released. Any objections?
@tux-rampage I think this particular patch is premature; we need changes proposed to zend-servicemanager-di first.
@weierophinney do you mean before we can release a 3.1 of zend-di? No question for the merge, that's why I want to Target it for 3.2 or later. The backporting work for zend-servicemanager-di will take some time.
@tux-rampage I'm saying this patch is irrelevant until we have a new zend-servicemanager-di release that has backports available.
We can continue doing releases of zend-di; we just can't do this patch yet, as we cannot guarantee there will be a compatible release of zend-servicemanager-di yet.
Thanks for the clarification @weierophinney
I'll remove the milestone for now and and set it as soon as we got a compatible release of zend-servicemanager-di
.
This will not be completed before the Laminas migration, so I'll close this PR in favor of the issue #58 to ease the migration to Laminas.
Provide a narrative description of what you are trying to accomplish:
ZF is aiming to allow easy migrations to new component versions whenever possible. For zend-di there is a component that integrated version 2 into zend-servicemanager. Version 3 introduced a conflict-entry in it's composer.json, that states clearly zend-servicemanager-di is no longer needed. But it will also urge consumers to potentially upgrade many parts of their application.
To make life easier for these users, we should provide a new version for zend-servicemanager-di, that will deprecate it's own usage but allowing the user's to remove it's parts step by step.
This PR requires changes in [zend-servicemanager-di] and must not be merged without them.
I'll open a discussion about this in discourse about this issue. If the suggested changes to zend-servicemanager-di will be rejected by the framework group, this PR will be rejected as well.
Edit: Link to the discourse topic
[x] Are you creating a new feature?
develop
branch, and submit against that branch.CHANGELOG.md
entry for the new feature.[x] Is this related to quality assurance? Improves version migration (see above)