Roadmap to stable v1.0.0

[clue]

Let's face it, this project is currently beta, but has been used in production for years

We're currently following a v0.X.Y release scheme (http://sentimentalversioning.org/).

We should finally make this stable and fully adhere to SemVer and release a stable v1.0.0.

To a large extend, a stable v1.0.0 helps making BC breaks more explicit and thus the whole project more reliable from a consumer perspective. This project is actively maintained and has received some major updates in the last weeks and has some major updates planned in the next weeks. Given our current versioning scheme, we'd like to ensure all anticipated BC breaks will be merged before the planned v1.0.0 release.

As such, I've set up a roadmap that enlists only the major changes for each version among with planned release dates towards a stable v1.0.0 release:

v0.4.4 ✅

• Released 2017-02-13
• Headers PSR-7 and case-insensitive
• Version constraints
• Stream empty data events and back-pressure

v0.5.0 ✅

• Released 2017-02-16
• Request PSR-7 methods
• Reduce public API
• Socket component v0.5 and secure HTTPS

v0.6.0 ✅

• Released 2017-03-09
• Chunked transfer encoding and Content-Length
• Stream data, end and close behavior
• Stream v0.5 API
• HTTP/1.1 and HTTP/1.0
• No longer considered beta quality

v0.7.0 ✅

• Released 2017-05-29
• Streaming PSR-7 support
• Request-In-Response-Out callbacks

v0.8.0 ✅

• Released 2017-12-12
• Full PSR-7 support
• Form submissions, including POST fields and file uploads
• Middleware request handler arrays

v1.0.0 ✅

• Released 2020-07-11
• New HTTP client
• Clean up Server APIs
• LTS

This ticket aims to serve as a basic overview and does not contain every single change. Please also see the milestone links and the CHANGELOG for more details.

Obviously, this roadmap is subject to change and I'll try to keep it updated as we progress. In order to avoid cluttering this, please keep discussion in this ticket to a minimum and consider reaching out to us through new tickets or Twitter etc.

[clue]

Updated now that the v0.5.0 release is out

https://github.com/reactphp/http/milestone/2

[WyriHaximus]

With no changes between 0.8.0 and 1.0.0, does it make sense to go full PHP 7+, scalar type hints, return type hints etc etc, with 1.0.0? Making 0.8.x targeted for PHP 5 and 1.x for PHP 7.

[clue]

go full PHP 7+, scalar type hints, return type hints etc etc

I'm open for this and would like to discuss the pros and cons of this in a separate issue 👍 Do you feel like filing an issue to spark the discussion?

That being said, unless we bring up some very good points for this, I would tend to vote against getting this in for 1.0.0 yet. We may totally release a v2.0.0 a month after v1.0.0 though, if we see this provides substantial benefits 👍

My idea here would be to provide some (limited) long-term support for older versions on the stable v1 series (similar to how our Promsies work) and then look forward for upcoming major releases 👍

[WyriHaximus]

That being said, unless we bring up some very good points for this, I would tend to vote against getting this in for 1.0.0 yet. We may totally release a v2.0.0 a month after v1.0.0 though, if we see this provides substantial benefits 👍

That makes perfect sense, I'll file an issue on the meta repo 👍

[clue]

Updated the upcoming v0.6.0 milestone to also include the Stream v0.5.0 changes that are planned: reactphp/stream#67

[clue]

Updated now that the v0.6.0 release is out 🎉 🎉

[andig]

I'm really happy about the progress react is making lately. However, I'm wondering what the approach will be towards using ServerRequestInterface instead of RequestInterface. Ringcentral currently doesn't have it and also does not have any PR queued up. If that the only blocker would moving to guzzle be a cure?

[clue]

@andig Do you mind if we move this discussion to #28 instead? Afaict @legionth has made some very good progress with the ServerRequestInterface and it basically only adds a few methods to the existing RequestInterface, so I don't really see this blocking the process for much longer anyway 👍

[andig]

Checking back in the hope of not being too big a nuisance. Imho 0.7 has all the features that were planned. In order to pave the way for the much-desired 0.8 would it be time to release 0.7 and move on to body parsers?

[WyriHaximus]

@andig only outstanding issue is #98 / #159 for v0.7. Already started working on v0.8 locally 😄

P.S. No you're not a nuisance

[clue]

Updated now that the v0.7.0 release is out 🎉 🎉 🎉

[andig]

ping @WyriHaximus any news on 0.8 or enjoying a nice vacation ;?

[WyriHaximus]

@andig Big PR coming soon 🎉 will ping you in it 😎

[christoph-kluge]

With no changes between 0.8.0 and 1.0.0, does it make sense to go full PHP 7+, scalar type hints, return type hints etc etc, with 1.0.0? Making 0.8.x targeted for PHP 5 and 1.x for PHP 7.

I would suggest to take a look at the currently supported versions by the php-group. There are no security patches anymore for < 5.6. So we might be able to drop the support for 5.3 - 5.5 and keep only maintenance for 5.6 in v1 version.

v0.8.0 / v1.0.0

Another topic: What about keep-alive support? Is this planned to be included in 0.8 - 1.0? I'm already looking into #9 and #76 and some other projects to see how we can achieve that for the current master.

[nusje2000]

When will version 0.8.0 drop, I cant wait to use the body parser so I can finally use POST requests :o

[WyriHaximus]

@nusje2000 soon, very soon. We only have four outstanding issues/PR's for 0.8 before it can be released: https://github.com/reactphp/http/milestone/14

[andig]

@WyriHaximus I realize it's not ready and not tagged for 0.8 but I'd appreciate if we could discuss if #235 can be part of the release especially as it would- if not changing the api- be changing the request structure of the server. Discussion is in #232.

[WyriHaximus]

@andig ah yes it's on my todo list for today. And I can assure you that will be included in v0.8.0

[nusje2000]

@WyriHaximus If there is anything I can do to help you guys out (and to reach 0.8.0), I would love to hear it.

[WyriHaximus]

@nusje2000 the easiest way to have is to use dev-master and test it out in your project and report any issues you encounter and any other feedback you have.

[nusje2000]

@WyriHaximus @clue Is it correct that the HttpBodyStream is not completed yet ?

Edit:
Never mind, I forgot to add the RequestBodyBufferMiddleware middleware.

[clue]

Updated now that the v0.8.0 release is out 🎉 🎉 🎉

[DanielOverdevest]

When do you think a stable V1.0.0 version is launched? I see for some other reactPHP packages that you reached this milestone. Curious to know what the future will bring!

[legionth]

@DanielOverdevest I think this is a stable library for a while now. The v1.0.0 would be just an offical marker.

The only component missing is a proper HTTP client. I think the plan is to merge @clue's https://github.com/clue/reactphp-buzz into this library.

[DanielOverdevest]

I'm very surprised with the possibilities of ReactPHP. I'm using ReactPHP datagrams already in production for a while. But want to extent it also with a very smalle HTTP(S) server for some health checks. So was thinking what service would suits in the setup I already have.
I think this http lib would work for me.

I'm also using the reactphp-buzz, indeed would be nice to incorporate in this github project.

Many thanks for the wonderfull work!

[WyriHaximus]

The only component missing is a proper HTTP client. I think the plan is to merge @clue's https://github.com/clue/reactphp-buzz into this library.

So the plan with that is the merge buzz into http-client and then merge http-client into http

[clue]

The very first stable v1.0.0 release with LTS has just been tagged and released! 🎉🎉🎉