Require PHP 7.2 or newer

[Art4]

Hi all 👋

This PR increases the required PHP version to 7.2 or newer. I propose this PR for SimplePie 1.8 (see Roadmap in #731).

Increasing the PHP version to 7.2 will give us some new features:

• Return type declarations
• Strict typing (declare(strict_types=1);)
• Anonymous classes
• Nullable types
• Void functions
• Symmetric array destructuring (already used in this PR)
• Class constant visibility (already used in this PR)
• Abstract method overriding
• Parameter type widening

It will allow us to support PSR-18 HTTP client (see #520)

Based on the download numbers from packagist.org (see below) I would say that it is save to increase the PHP version to 7.2. But I would also like to hear feedback from projects like WordPress (ping @rmccue) and FressRSS (ping @Alkarex).

Downloads for all SimplePie versions

Over 96% of all downloads are on PHP 7.2 or newer.

Downloads for SimplePie version 1.6

Looking only at SimplePie 1.6 over 98% of all downloads are on PHP 7.2 or newer.

[Alkarex]

But I would also like to hear feedback from projects like WordPress (ping @rmccue) and FressRSS (ping @Alkarex).

We are about to release FreshRSS 1.20.x supporting PHP 7.0 but from FreshRSS 1.21+ we will require PHP 7.2+

We are more or less tracking Debian and Ubuntu LTS (Debian 9 Stretch supported PHP 7.0 until June 2022)
FreshRSS/FreshRSS#3321 (comment)

[Alkarex]

P.S. What about WordPress? It is shipping SimplePie, right? And still supporting PHP 5.6.20+

• https://github.com/WordPress/wordpress-develop/tree/trunk/src/wp-includes/SimplePie

---

• https://make.wordpress.org/core/2020/08/24/proposal-dropping-support-for-old-php-versions-via-a-fixed-schedule/#comment-39736
• https://core.trac.wordpress.org/ticket/33381
• https://core.trac.wordpress.org/ticket/51043

[Art4]

P.S. What about WordPress? It is shipping SimplePie, right? And still supporting PHP 5.6.20+

Yes, I would very much appreciate feedback from WordPress. Maybe @jrfnl could help us?

[jrfnl]

Thank you very much for the ping @Art4 !

You are 100% correct, SimplePie is shipped with every download of WordPress and this will not show in the Packagist's stats as WP does not manage its non-dev dependencies via Packagist, nor does it manage its distribution via Packagist.

While there are always discussions on-going in the WordPress community about dropping support for certain PHP versions on the lower end (and I won't deny that I'm regularly an instigator of those 😇), at this time, I expect no movement away from the PHP 5.6 minimum in the near future.

WordPress generally bases these type of decisions on real-life stats of WordPress installs. The sum-total of the users on PHP versions for which support will be dropped needs to be less than 5% of all WordPress users.

If we look at the current stats, you can see that PHP 5.6 still represents 5.8% of the user base, PHP 7.0 3,1% and PHP 7.1 2.2%, which comes to a sum-total of > 11% of the users.

Please keep in mind that 1% of users for WordPress is > 1 million +/- 0.5 million sites (I'd need to ask around to get a more precise number), so blocking the upgrade path for millions and millions of WP sites is always something which needs very careful consideration.

Having said all that, and though I cannot speak for the WordPress project as such, I do believe it would be greatly appreciated if the minimum supported PHP version for SimplePie would remain at PHP 5.6 for a while longer.

All the same, SimplePie is an independent project, so if you do decide to up the minimum supported PHP version, WordPress would just have to deal with it until the WP minimum supported PHP version will go up.

In practice this would mean:

• Backporting security fixes (if any).
• Backporting PHP cross-version compatibility fixes.

Speaking personally and from a maintainer point of view, I do think it would be better for a version drop like this to go into a major release (2.0), not a minor (1.8). As said before, not all downloads/installs go via Composer, so including this in a major will more clearly signal that people need to pay close attention to the changelog when upgrading.

Hope this helps and gives some perspective.

P.S.: I've also pinged the maintainers of the WordPress "External Libraries" component with a link to this ticket, so they may pitch in with an opinion later.

[Art4]

Thanks for the detailed explanations @jrfnl.

I can't speak for the SimplePie team, but based on the roadmap (#731) I can imagine the 1.7 branch as the LTS branch for PHP 5.6 support. If WordPress switches to namespaced classes (src folder), backports of bugfixes will be much easier.

In version 1.8 we could bump to PHP 7.2+ and add alternatives to the cache and HTTP client implementations. However, I could also imagine just bumping to PHP 7.0+ instead of 7.2+. This would complicate the upgrade process, but it would allow WordPress to move to a newer version once PHP 6.5 support is dropped.

With 1.9 we could add warnings about deprecated code as a helpful upgrade layer, and with version 2.0 we will remove all deprecated code.

Or to summarize all this in a table:

Version/branch	Status	requires	First release	Latest patch
1.3.x	❌ Unsupported (eol)	PHP 5.2.0+	1.3 (2012-07-07)	1.3.3 (2021-12-24)
1.4.x	❌ Unsupported (eol)	PHP 5.3.0+	1.4 (2016-04-26)	1.4.3 (2016-11-27)
1.5.x	❌ Unsupported (eol)	PHP 5.6.0+	1.5 (2017-04-17)	1.5.8 (2021-12-21)
1.6.x	✅ Supported	PHP 5.6.0+	1.6.0 (2022-04-21)	1.6.0 (2022-04-21)
1.7.x	🏗️ WIP (Switch to PSR-4, LTS)	PHP 5.6.0+
1.8.x	🏗️ WIP (PSR-16/18 support)	PHP 7.0+ or 7.2+
1.9.x	💭 Add deprecation warnings	PHP 7.0+ or 7.2+
2.0.x	💭 Remove deprecated code	PHP 7.0+ or 7.2+

[jtojnar]

I do not think raising minimum PHP version in minor version would be compatible with semver. It should be done in 2.0.0.

Deprecations should be added in minor versions according to point 7 of semver.

So maybe 1.8 + 1.9 should just become 2.0. And 2.0 → 3.0. And 2.0 does not need to have a support window, it can just serve as a migration step.

[Art4]

I do not think raising minimum PHP version in minor version would be compatible with semver. It should be done in 2.0.0.

Deprecations should be added in minor versions according to point 7 of semver.

Increasing the minimum PHP version is not a deprecation, but a change in dependencies. Just as requiring another library as a new dependency is not a breaking change either. Before installing the new version of a library, one must always check if one meets the requirements of the new version. If not, one have to keep the old version. Composer does this automatically and will not allow you to install the new version if the new requirements are not met.

This is also clarified in semver.

So maybe 1.8 + 1.9 should just become 2.0. And 2.0 → 3.0. And 2.0 does not need to have a support window, it can just serve as a migration step.

My proposal is that version 1.9 will be this migration step.

[skyzyx]

@jtojnar said:

I do not think raising minimum PHP version in minor version would be compatible with semver. It should be done in 2.0.0.

Deprecations should be added in minor versions according to point 7 of semver.

SemVer is for defining how a software contract changes over time. However, it does not cover what is in-bounds/out-of-bounds for that software contract. The fact is: SimplePie needs a software contract to go along with SemVer versioning to define exactly this.

My opinion is that since PHP versions go EOL annually, it doesn't make sense to have a major version bump every year. SimplePie 1.0 went live in 2006(?) and supported PHP 4.3. We've dropped several versions of PHP since then.

Also, old versions of SimplePie still work. If you are still running an EOL PHP runtime, then you can run an old version of SimplePie. The version you have won't suddenly stop working.

If it were up to me, SimplePie would not consider EOL compatibility in new features or refactorings. PHP 7.4 goes EOL this November/December and only 8.x will be left in supported status. I think it's extremely generous that this PR supports back to PHP 7.2.

To agree with @Art4: We should be dropping support for old versions of PHP annually. If WordPress wants to support PHP 5.6, then they can. But it'll be an older version of SimplePie. While I genuinely do appreciate reaching out to affected software projects about compatibility so that everyone can work together, I disagree that those projects should hold SimplePie back.

If only we had something like Babel.js for PHP…

[jtojnar]

SemVer is for defining how a software contract changes over time. However, it does not cover what is in-bounds/out-of-bounds for that software contract. The fact is: SimplePie needs a software contract to go along with SemVer versioning to define exactly this.

Good point. In an absence of such contract, I was basing the suggestion on best practices from the Node ecosystem, where bumping the major version occurs when a support for a Node dependency is dropped. For PHP, we would need to apply this even for any change in dependency bounds in composer.json, since PHP unlike NPM does not support multiple versions of the same library in the dependency tree (unless the symbols are renamed). That probably is not reasonable.

If only we had something like Babel.js for PHP…

We do 😉 It works pretty well for me for various refactoring tasks (e.g. j0k3r/graby#282, RSS-Bridge/rss-bridge#2910) and there are people using it to develop in PHP 8.1 and transpile the artifacts downwards.

[mblaney]

I think it is important to consider WordPress a special case, but the current version of SimplePie included with it is stable, which means WordPress users aren't asking for updates (like has happened previously). To me that means it's ok to make our own decisions and I tend to agree with dropping support for the older versions of PHP.

The recent changes to SimplePie have been great and mostly aimed at modernizing the code base. Seems reasonable given the direction taken that older versions of PHP are dropped so that newer features of the language can be used.

[Alkarex]

But so far, SimplePie is only maintaining a single branch, right?
What would be the workflow for e.g. WordPress or others interested in stability rather than fancy new language features, to get new features and security fixes? Fork SimplePie and backport relevant changes?

[Art4]

@Alkarex good question. I would suggest introducing a new branching workflow, which is then also described in the README.md. If you think about my suggestion above with the table, the branches could look like this:

• v1.7-lts (LTS for PHP 5.6)
• v1.x (Other 1.x versions like 1.8.0, 1.9.0, etc)
• v2.x (All 2.x versions like 2.0.0, etc.)

Bug fixes or security fixes are created in the latest branch (v1.x or v2.x) and can then be backported to the v1.7-lts branch.

The current master branch will then no longer be needed.

[Art4]

If we look at the current stats, you can see that PHP 5.6 still represents 5.8% of the user base, PHP 7.0 3,1% and PHP 7.1 2.2%, which comes to a sum-total of > 11% of the users.

Today after 30 days PHP 5.6 has 5,5%, PHP 7.0 has 3,0% and PHP 7.1 has 2,1% user base, which comes to a sum-total of 10,6%. Based on these falling numbers, I would guess that the LTS branch will not be needed for very long.

Update 2022-11-17: Today after 79 days PHP 5.6 has 5,2%, PHP 7.0 has 2,8% and PHP 7.1 has 1,9% user base, which comes to a sum-total of 9,9%.

[Art4]

@mblaney What do you think about the idea of a new branching strategy? Now that version 1.7.0 is released, it would be the perfect time to do so. The roadmap for that might look like this:

1. Rename branch master to v1.x (v1.x will be the new default branch)
2. Create new branch v1.7-lts from v1.x branch.
3. Edit README.markdown to explain new branching strategy. I can create a PR for this.
4. Merge this PR into v1.x branch
5. Add note in v1.7-lts branch about LTS. I can create a PR for this.

[Art4]

I moved the the discussion and necessary changes for a new branching strategy to #751.

[mblaney]

this looks good to merge now?

[Art4]

this looks good to merge now?

After the merges of the other PRs I will have to take a look again for more changes.

[Art4]

this looks good to merge now?

@mblaney This PR is now ready for merge.