Skip to content

Move plugins #70

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 4, 2016
Merged

Move plugins #70

merged 1 commit into from
May 4, 2016

Conversation

sagikazarmark
Copy link
Member

Although there will be no version two, I added it so that in any case, we can continue using this package if necessary (like a metapackage installing all plugins, discussed elsewhere).

Also, please let me know what you think about the compatibility layer:

  • Old plugin interface extends the new one, no API change
  • Old plugin client wraps the new one


/**
* The client managing plugins and providing a decorator around HTTP Clients.
*
* @author Joel Wurtz <[email protected]>
*
* @deprecated since since version 1.1, and will be removed in 2.0. Use {@link \Http\Client\Common\PluginClient} instead.
*/
final class PluginClient implements HttpClient, HttpAsyncClient
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we simply extend the base plugin client and add nothing? as the plugin interface extends the base plugin interface, everything should "just work". or is the base client final?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No we can't:

  • The base client is final
  • We would still have to do some hacks to throw the correct exception (in which case the exception is also final, so extension is not an option there)

@dbu
Copy link
Contributor

dbu commented May 4, 2016

looks good. and we actually should release that as 1.1 at some point. otherwise people that use stable deps will never see the deprecations in their code.

we could also add the trigger_error code like symfony does, to see deprecation errors when enabled. https://knpuniversity.com/blog/upgrading-symfony-2.7

@sagikazarmark
Copy link
Member Author

we could also add the trigger_error code like symfony does

Ah, wanted to, but forgot it.

Provide cross-compatibility between new and old plugins

The deprecated PluginClient now wraps the new one internally
and dispatches the requests to it.
Full BC should be preserved, relevant exceptions caught
and rethrown with the appropriate wrapping.

Add deprecation error triggering
@sagikazarmark
Copy link
Member Author

Merge and tag?

@dbu dbu merged commit e05577d into master May 4, 2016
@dbu dbu deleted the move_plugins branch May 4, 2016 13:06
@dbu
Copy link
Contributor

dbu commented May 4, 2016

👍 i let you tag if all is ready.

@sagikazarmark
Copy link
Member Author

Hm, what else to do?

Only the separate packages are not tagged, everything else is.

@dbu
Copy link
Contributor

dbu commented May 4, 2016

i think we should tag those (if they are ready to be tagged) before we tag this. when people discover they should move, the move target should be released and ready :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants