Closed driesvints closed 4 years ago
Hello @driesvints !
nexmo/client
generally only gets tagged for major releases, or for releases to help with testing for RC releases of nexmo/client-core
. The current version lock inside nexmo/client
should pull in the latest major version of nexmo/client-core
it's tagged against, so nexmo/client
should currently be pulling in nexmo/client-core:2.2.1
. It doesn't necessarily have to be lock-step with the same version number as core.
This setup actually gives the user the ability to help swap out the underlying HTTP client, which this change will force them into Guzzle 6. We do this dual-package split to give users a workaround if they rely on an older version of Guzzle (or new, with Guzzle 7's release), or want to use the Symfony HTTPlug adapter. Locking nexmo/laravel
to Guzzle 6 will likely cause composer conflicts.
I'm not sure why the referenced ticket says there is no 2.0.0 tag. A tag exists at https://github.com/Nexmo/nexmo-php-complete/tree/2.0.0, and https://packagist.org/packages/nexmo/client#2.0.0 shows the tag is available. Is the notification channel package not picking up the correct versions?
@dragonmantank hey Chris, thanks for the thorough explanation! That definitely makes sense.
I completely mislooked. Seems like for some reason the release candidates were tagged later than the 2.0.0 tag:
So this should be good. Thanks again! :)
nexmo/client
is lagging a bit behindnexmo/client-core
(no stable 2.0 version yet). Since it's just an empty package I think we can safely usenexmo/client-core
directly here. I've also directly required the Guzzle adapter here instead. This was thenexmo-laravel
package has one less package in between and you don't have to worry about taggingnexmo/client
anymore.