Removed the zend-servicemanager usage #47
Conversation
| @@ -14,15 +14,14 @@ | |||
| }, | |||
| "require": { | |||
| "php": ">=5.5", | |||
| "zendframework/zend-crypt": "~2.5", | |||
| "zendframework/zend-crypt": "dev-develop as 2.6.0", | |||
There was a problem hiding this comment.
If we're removing zend-servicemanager as a dep, the change is essentially backwards compatible.
Couldn't this dependency be ^2.5 || ^3.0? That would make it possible to keep this component in the 2.X series.
|
With the suggested changes, we can target 2.6.0 instead. 😄 |
|
👍 👍 |
|
@weierophinney the PR is ready to be merged. |
| @@ -14,15 +14,15 @@ | |||
| }, | |||
| "require": { | |||
| "php": ">=5.5", | |||
| "zendframework/zend-crypt": "~2.5", | |||
| "zendframework/zend-crypt": "^2.5 || ^3.0", | |||
There was a problem hiding this comment.
@Maks3w the Composer documentation for that is inconsistent, and uses both. As the parser accepts either, I think using || makes sense, for its affiliation with the language itself.
Removed the zend-servicemanager usage
|
@weierophinney AFAIK Zend Framework is following SemVer, isn't it? Because I just updated my dependancies, and everything broke up because API totally changed in a non BC way. This PR should be tagged 3.0.0, not 2.6.0, like what it was done to other 2.6 components. |
|
@Slamdunk What breakage are you seeing in this component, specifically? |
|
The fact that all the public method of Or in the SemVer the API are only the ones listed in an Interface, in this case |
|
@Slamdunk You're missing the point of my question: has any code of yours specifically broken? If so, what specifically? Any code snippets of something you were actually using that no longer works would be useful. The plugin manager implementation in this component was by-and-large an implementation detail, which is why we felt it was safe to refactor it to be standalone; however, I'd like to see if people were relying on the fact that it was an |
|
Let me preface this comment by saying that refactoring my code to this PR was a matter of seconds; my speech was more a matter of theory on SemVer than a complain. As posted on #27 I need a custom After the update this behaviour produced a SemVer says:
Well, a |
|
@Slamdunk You've provided me the information I was looking for: you were using the features inherited from Thanks for providing me the usage detail! |
This patch re-implements the SmtpPluginManager as a zend-servicemanager AbstractPluginManager, as was the behavior before 2.6.0. As reported on zendframework#47, making the implementation standalone was a backwards compatibility break, as it was not an internal implementation only, but also the documented mechanism for providing additional featuresets and/or overriding the functionality of existing features. To accomplish this, the following changes were made: - Added a development requirement on zend-servicemanager `^2.7.5 || ^3.0.3`. - Added a `suggest` section, recommending zend-servicemanager when using the SMTP transport. - Added compatibility tests for the `SmtpPluginManager`, to assure equal behavior between v2 and v3 of zend-servicemanager. - Updated `SmtpPluginManager` to extend `AbstractPluginManager` and define aliases and factories for the shipped protocol plugins.
|
@Slamdunk If you update to zend-mail 2.6.1, we've restored the |
This PR removes the usage of zend-servicemanager using a custom SmtpPluginManager. This removal simplify the usage of the component.