We keep also support for previous version. Now it depends on the library consumer what version of http-middleware to use. We accomplish that by using external library webimpress/http-middleware-compatibility.
Please note that tests runs with lowest/locked/latest dependencies. I've set composer.lock on http-middleware 0.4.1, lowest will be 0.1.1 and latest 0.5.0. All test pass :)
Probably we don't need support version http-middleware 0.1.1 anymore, so can add conflict condition in composer. To support it, I've added in two place method next as proxy to method handle (also new method, to support http-middleware 0.5.0) - and now process is proxy to handle.
Definitely we need update documentation a bit more. I'm thinking about all examples in documentation. How we should do that? Use always http-middleware interfaces (what version?) or aliases from webimpress/http-middleware-compatibility? IMHO, final library users should use http-middleware interfaces directly.
We keep also support for previous version. Now it depends on the library consumer what version of http-middleware to use. We accomplish that by using external library
webimpress/http-middleware-compatibility
.Please note that tests runs with lowest/locked/latest dependencies. I've set
composer.lock
on http-middleware 0.4.1, lowest will be 0.1.1 and latest 0.5.0. All test pass :)Probably we don't need support version http-middleware 0.1.1 anymore, so can add conflict condition in composer. To support it, I've added in two place method
next
as proxy to methodhandle
(also new method, to support http-middleware 0.5.0) - and nowprocess
is proxy tohandle
.Definitely we need update documentation a bit more. I'm thinking about all examples in documentation. How we should do that? Use always
http-middleware
interfaces (what version?) or aliases fromwebimpress/http-middleware-compatibility
? IMHO, final library users should use http-middleware interfaces directly.