Roadmap for Requests 2.0

[jrfnl]

@schlessera and me had a call yesterday. This issue will share some conclusions from that call, as well as contain a proposal for next steps.

Planning

The current planning is to release version 1.8.0 very soon, as in: within the next few weeks.
That will be the last release supporting PHP < 5.6.

After that release, work will start on version 2.0.0, for which the most important change is the change in the minimum supported PHP version.
While the version drop doesn't have to be in a major release, we are aware that not all projects which use this package use Composer to install it, which is why we are making a deliberate choice to move the version drop to a major release.

Initial proposal for changes to be included in 2.0.0

• Drop support for PHP < 5.6. See Drop support for PHP < 5.6 & PEAR #470
  • Adjust the composer.json file
  • CI: stop running tests and stop linting against PHP < 5.6
  • Adjust relevant documentation
• Drop support for PEAR. See Drop support for PHP < 5.6 & PEAR #470
• Move away from Travis onto GH Actions for CI. See Replace Travis CI with GitHub Actions workflows #447.
• Remove work-arounds in place throughout the codebase for support of PHP < 5.6.
• Namespace all classes, both functional classes as well as the tests. See Tests: introduce namespaces #503 for the test namespacing. See Requests 2.0.0: introduce namespaces #519 for the src namespacing
• Implement use of the PHPUnit Polyfills package to gain cross-version PHPUnit compatibility for the test suite, which will make it easier to run the tests on new PHPUnit and PHP versions. See Replace PHPUnit 6+ compat code with Yoast PHPUnit polyfills package #446.
• Make any obvious and simple code modernizations which can now be made. Think: use of __DIR__, use of short arrays, etc. Related PRs: Modernize: use magic __DIR__ constant in lib code and example code #504, Modernize: use the magic ::class constant #506, CS: use short arrays #623 (more to follow)
• 🆕 Support PHP 8.0 named parameters. See PHP 8.0: full review for named parameters #533, PHP 8.0: ensure parameter names are aligned with PHP native param names #560, QA/PHP 8.0 | Don't use reserved keywords as param names #561, PHP 8.0 | Hooks::dispatch(): prevent potential fatal error #599, Session: rename magic method parameters #612
• 🆕 Add support for PHP 8.1. See PHP 8.1: improve input validation for Requests_Transport_(fsockopen|cURL) #499, PHP 8.1: fix deprecation notices in Requests_Transport_cURL #500, GH Actions: run tests against PHP 8.1 #501, PHP 8.1: fix deprecation warnings #505. Also related: Add input validation #593
• 🆕 Drop support for HHVM. See Drop support for HHVM #509
• 🆕 Remove previously deprecated code. See Clean up: remove previously deprecated methods #510

Initial planning for 2.0.0

The current idea is to release version 2.0.0 soon after 1.8.0 without significant functional changes, though functional change PRs which are, or become, ready to merge during the 2.0.0 development cycle will definitely be considered for inclusion.

Call for contributors

Once work on 2.0.0 starts, @schlessera and me plan to have one or more public triage calls or Slack meetings (format to be determined) in which we'll go through open issues and open PRs to determine next steps: rebase, finish off and merge, milestone as a viable feature for a future release or close.

We'd very much would like to welcome anyone who wants to contribute to this repo to those calls and would very much welcome contributions to any open actions which will result from those calls.

As soon as a date and time for the first triage call has been set, it will be announced here.

[jrfnl]

Just thinking: I'd like to suggest dropping support for releasing the package via PEAR in v 2.0.0 as well.

If so, this should probably also be mentioned in the changelog of 1.8.0 re: "Upcoming changes". /cc @schlessera

[jrfnl]

For anyone watching this ticket/this repo:

We're currently planning two triage sessions for Requests 2.0 and would welcome anyone who's interested in contributing to join us. We'll be going through some of the open PRs, testing them, and generally trying to get them ready for merging.

The triage sessions are currently planned for:

• Friday August 20, 07:00 - 11:00 UTC
• Friday September 3, 07:00 - 11:00 UTC

Please leave a message here if you'd like to join in!

[jrfnl]

Also an update on the planning for Requests 2.0:

As there are a number of PHP 8.1 related fixes which have recently been merged, we'd like to do a release well in time before the PHP 8.1 general release, so any libraries and frameworks using Requests will have a PHP 8.1 compatible version available in time.

With that in mind, the current planning is:

• Release an RC on September 16, 2021.
• Release version 2.0 on September 30, 2021.

Obviously this planning is subject to change, but we'll try to stay relatively close to it.

[jrfnl]

Another one to consider dropping support for and removing all references to it in codebase and docs: HHVM.

I've come across a few references in the codebase, but can hardly imagine that Requests still works properly with HHVM given that HHVM dropped support for PHP at the end of 2018.

@schlessera Do you agree ?

[jrfnl]

After discussion today and with the test PR for WordPress passing, we've decided NOT to do an RC release.

The tentative release for the 2.0.0 version remains September 30, with a two-week delay window if needs be.

[jrfnl]

Closing as released: https://github.com/WordPress/Requests/releases/tag/v2.0.0