Release 2.0

[Jean85]

During #114 we started working toward a 2.0, with a dedicated branch. With that merged, 2.0 is compatible with HTTPlug 2 and PSR-18. What else do we want to add? I'll try to suggest some stuff and track it here. Maybe we can use a milestone?

• [ ] Update the docs/changelog
• [x] Use PHP 7 language features, since it's now the minimum
  • [x] Scalar type in method parameters and return types
• [x] Remove deprecations
• [x] Make all classes that are not intended to be extended final, verify that everything that is protected really needs to be protected

[sagikazarmark]

Good idea, added something too.

I would probably wait with tagging until we actually have a client that we can use with this package, but Guzzle adapters will probably be tagged by then.

[dbu]

:+1: i edited the PHP 7 thing to be more concrete. did you have other things in mind? we should focus on potentially BC breaking things. we can optimize implementation constructs after 2.0 is released, but method signatures, visibility/removing deprecations and final etc are BC breaks that we want to do now.

[Jean85]

We should add #20 to this list.

[dbu]

there is https://github.com/php-http/client-common/milestone/3 - imho we should use the milestone to group all tasks for the 2.0 release.

[mxr576]

Any ETA for the 2.0.0 release?

[Nyholm]

We will release it before Wednesday. @mxr576 Do you want to help review it and make sure every thing is correct?

[mxr576]

Yes, I am happy to help. I am also updating my library's dependencies in this week. I'll give it to try to #141 which was a follow up on #113. Of course, validate all other changes in the master branch with my libs automated tests.

[Nyholm]

That would be great.

Im pretty sure that current dev-master will be tagged 2.0. We just need more people testing it and review it.

[dbu]

i tagged 2.0.0-RC1 just now. please report issues if you can find any.

[mxr576]

Type-safe coding is an essential and a long awaited feature in PHP but it is ... when you trying to support multiple major versions from the same library. It seems my lib can not support both the 1.x and 2.x version from this library within the current 1.x major release thanks to parameter type changes like this: https://github.com/php-http/client-common/commit/68713627e85434c1a20529e8c108ce0c0938950b#diff-3f5c1f14c77b75e280cc2e297cce7d70R32. https://github.com/apigee/apigee-client-php/blob/2.x/src/HttpClient/Utility/Journal.php#L71 :roll_eyes: :-(

TBC tomorrow...

[mxr576]

@Nyholm @dbu What are the support plans for the php-http 1.x packages (ex.: this one, https://github.com/php-http/httplug, https://github.com/php-http/guzzle6-adapter, etc.)? I have spent some time with evaluating how I could support both 1.x and 2.x versions from all php-http packages that I use. It would not be easy thanks to these PSR-18 related interface typehint changes and by knowing that the fix in #141 is only available in the 2.x branch. (Which seems to be working by the way. \o/ ) If you are not planning to support the 1.x branch in the long term run then I am not going to invest more time to find a solution that allows to support both in my lib. Moreover I may drop the support of the 1.x packages in a minor release of my lib in that case :roll_eyes: (2.0.0. stable from my lib has been release 2 months ago, not the best timing I know...)

[Nyholm]

They are going to be supported and bugfixed. But not developed.

php-http/httplug has not been updated in over 2 years so I dont think the 1.x branch will be updated anymore. It is about the same for guzzle6-adapter.

Im about to release a new major version of mailgun. I drop the httplug interface: https://github.com/mailgun/mailgun-php/pull/522 and before we have a new major version I include both v1 and v2 of httplug: https://github.com/mailgun/mailgun-php/blob/2.8.0/composer.json#L6

If you have a third party library that depends on client-common you should require ^1.9 || ^2.0. If you depend on php-http/httplug you should require ^1.0 || ^2.0.

A third party library should never care about the Guzzle adapter or any other client.

---

If you are just concerned about your application, then consider updating if you can. If you can't help your dependencies to update.

[joelwurtz]

IMO @Nyholm it depends on how you use php-http librairies, if it's only usage (not implementing any interface). You are safe to use both versions 1.0 and 2.0.

On the contrary if you implement some interfaces that has changed (like the JournalInterface that you report), then you need to use only 2.0 and maybe doing a Major Release if class that implement those interface can be extended by your users (as it will be a BC break for them)

[Nyholm]

Yes. Of course.

The 95% of uses there is nothing to worry about. But yes. The JournalInterface might cause issues for some. Actually, in the PR i linked, there is a solution: https://github.com/mailgun/mailgun-php/pull/522/files#diff-139957a89bba6a2a4538eeaa748da4d2R48

[mxr576]

Yes, unfortunately I am in the remaining 5% at this moment. :) I do not think that the upgrade to the 2.x versions is important in our case, it can be postponed still.

Is there any plan to backport #141 to to the 1.x branch? Can I work on that in a PR?

[Nyholm]

We can’t back port it because it would break BC :/

[dbu]

@mxr576 do you provide a reusable library that you want to work with httplug 1 and 2? or is it an application that you maintain? (and if its a public library, can you link us to the problematic parts so that i can have a look if i can suggest further things?)

for #141, you could provide your own add path plugin implementation in your library if you hit that problem and must stay on version 1...

[mxr576]

@dbu It is a public library, an API client for APIgee Edge. It is a lib that I am maintaining but I am not the only decision maker of its future. If I would be the only one then I would simply release a 3.0.0 from that (and drop the support of the 1.x php-http packages) because the 2.0.0 has been only released 2 months ago and probably our Drupal 8 connector module is the only one that uses that. (Which we maintain so we can update it easily.)

I tried to collect every info that I gathered here and by examining a code in this issue: https://github.com/apigee/apigee-client-php/issues/41

[dbu]

i looked into the code a bit and i am afraid i see no simple solution. client-common 1.9.0 has a lot of forward compatibility. but httplug itself can not be forward compatible because sendRequest has a return type declaration in psr-18.

if it would help you to have a httplug 1.x version where the exceptions implement the psr exception but the client does not implement psr, i think we could do that. would that help?

[dbu]

2.0 has been released