Possible roadmap

[Art4]

In this issue I collect the progress of the refactoring of SimplePie. This roadmap serves me as a central place for rough planning. Please note that the roadmap is only my personal proposal for the further development of SimplePie, but has not been officially confirmed by the SimplePie team.

I would love to hear feedback from the SimplePie team and community. Please share your thoughts on what you think of this roadmap.

Possible roadmap

All changes must be backward compatible to adheres Semantic Versioning. Breaking changes are allowed with the release of 2.0.0.

🚀 SimplePie 1.6.0

(Allow usage of PSR-4 namespaced classes)

• Merge of Add namespaced classes and PSR-4 support #711.
• Let users try out the new experimantal namespaced classes and collect feedback
• This will also allow us to get a better statistic data about used PHP versions on packagist.org
• discussion about the necessary changes in build/compile.php or the need at all. Upload compiled file as asset + tests #725
• Merge of New Release 1.6.0? #726

🚀 SimplePie 1.7.0

(Refactoring to use PSR-4 internally, refactoring tests)

• Merge of Use PSR-4 namespaced classes #722.
• Copy the tests and change them to test the namespaced classes: Create tests for PSR-4 classes, refactor oldtests #730
• Switch to Code Style PSR-12: Change code style to PSR-12 #738
• Merge of Release 1.7.0 #733

🚀 SimplePie 1.8.0

(Allow external cache implementations)

• Raising the minimum PHP version based on download numbers and feedback: Require PHP 7.2 or newer #743
• Allow the usage of PSR-16 cache implementation (requires PHP >=5.3.0): Allow usage of PSR-16 cache implementation #742
• deprecate the usage of internal cache implementation (provide PSR-16 implementation instead): Use Psr16 cache as Default, deprecate \SimplePie\Cache\Base implementations #752
• Create interface RegistryAware: Create interface RegistryAware #760
• declare strict_types=1 in every file: Declare strict_types=1 in every file #763
• Registry: Allow using class-strings instead of magic strings: Registry: Allow using class-strings instead of magic strings #766
• Merge of Release 1.8.0 #761.

🏗️ SimplePie 1.9.0

(Allow external HTTP libraries)

• Add parameter type declarations in all classes (no BC break thanks to parameter type widening in PHP 7.2): Add type hints in all classes #775
• Remove obsolete phpdoc tags: [ENH] Revise the phpdoc tags @package and @subpackage #780
• Prepare File class as HTTP client: Split SimplePie\File class into HTTP client and response #774
• Replace the outdated idna_convert library: Use idn_to_ascii function instead of idna_convert library #785
• Allow the usage of Requests as HTTP client library (use an adapter instead)
• PHPStan Level 5 to fix issues from Declare strict_types=1 in every file #763: Raise PHPStan to level 6 #837
• Allow the usage of PSR-18 HTTP client library: Add support for PSR-18 HTTP clients #777
• Fixes for PSR-18 usage: Add support for PSR-18 HTTP clients #826
• Release SimplePie 1.9.0: Release 1.9.0 #850

🔲 SimplePie 1.10.0

(deprecate File, Locator, Sniffer classes and provide alternatives)

• Replace Locator and Sniffer with alternative: Replace Locator and Content\Type\Sniffer with Content\Detector #849
• deprecate the SimplePie\File class (provide HTTP client instead)
• Refactor exception throwing, deprecate the old error handling (enable_exceptions does not work properly in all cases #755)

🔲 SimplePie 1.11.0

(Trigger deprecation warnings to prepare for upgrade to SimplePie 2.0.0)

• Add option to throw or mute deprecation warnings
• Add deprecation warnings in all classes in library folder, see Add namespaced classes and PSR-4 support #711 (comment)
• Add deprecation warnings in all internal cache implementation (provide PSR-16 implementation instead)
• Add deprecation warnings in SimplePie\File (provide PSR-18 implementation instead)
• deprecate the single-file build because of external dependencies in v2
• deprecate the usage of PSR-0
• deprecate the usage of global constants like SIMPLEPIE_VERSION, use SimplePie\SimplePie::VERSION instead

🔲 SimplePie 2.0.0

(BC breaks are allowed; Require external HTTP library and cache implementation)

• Require PSR-16 cache implementation (use no cache as default)
• Require PSR-18 HTTP client implementation (use Requests as Default)
• remove single-file build because of external dependencies
• remove all deprecated code
• remove error handling and enable_exceptions, throw always exceptions
• remove the library folder
• remove tests for deprecated code

🔲 SimplePie 2.1.0

(To be determined)

• Raising the minimum PHP version to PHP 7.4 or PHP 8.0, based on download numbers and feedback
• Improve mf2 support: [ENH] Consider better mf2 support #684
• Add return types by introducing new methods (using camelCase) and interfaces, deprecate old methods without return types
• Split the feed-level methods out of the main SimplePie class. This will make the main SimplePie class the main API for setting options.
• Improve performance and memory usage. SimplePie's performance leaves much to be desired, so this should be the focal point of this release.
• Handle very large feeds, see XML parsing not in chunks, parser out of memory #598 and Handle very large feeds PressForward/pressforward#1040

Old ROADMAP.md

This roadmap is based on the (10 year old) ./ROADMAP.md that is now outdated.

# SimplePie Roadmap

This roadmap is a guide for what we're heading towards with SimplePie releases.
These are guiding features, however more may be included in each release.

## 1.4
* **Split the feed-level methods out of the main SimplePie class**

  This will make the main SimplePie class the main API for setting options.

* **Deprecate SimplePie_File**

  There are much better HTTP libraries out there than the included one. Instead,
  enable easy use of Guzzle and Requests via a new API, using Requests by
  default via Composer.

## 1.5
* **Improve performance and memory usage**

  SimplePie's performance leaves much to be desired, so this should be the focal
  point of this release.

## 1.6
* **To be determined**

[Art4]

The changes for PSR-18 support will take to long, but I would like to release the features for PSR-16 soon. I think it would be better to split the planned features for 1.8.0 into two releases.

[jtojnar]

Now that we have raised the minimum version of PHP above 7.0, we could start enabling the strict type checking) internally. @PHP70Migration:risky will do that, though maybe we will need to enable it progressively. Checking with PHPStan will probably be a good idea.

[Art4]

Now that we have raised the minimum version of PHP above 7.0, we could start enabling the strict type checking) internally. @PHP70Migration:risky will do that, though maybe we will need to enable it progressively. Checking with PHPStan will probably be a good idea.

Good point. I once tried to enable it everywhere while I was working on #743 and it fails catastrophically. 😅 Thats why I set 'declare_strict_types' => false, in .php-cs-fixer.dist.php. But it would be good to set the strict type at least in all new classes. I will check that and create a PR.

Update: see #763

[jtojnar]

@Art4 Regarding 1.9.0:

Unfortunately, there were several regressions like #810. We might either want fix all typing issues, possibly with the help of #837, or revert #763 for now.

• Allow the usage of Requests as HTTP client library

Do we need explicit support? Can’t the consumer just use your adapter library?

• Improve mf2 support: [ENH] Consider better mf2 support #684

I would remove it from 1.9 milestone unless we have someone interested in working on this.

[Art4]

Unfortunately, there were several regressions like #810. We might either want fix all typing issues, possibly with the help of #837, or revert #763 for now.

I definitely prefer #837. If a hotfix for e.g. 1.8.1 is needed I would prefer to remove the declare(strict_types=1); from the specific files instead from all files.

• Allow the usage of Requests as HTTP client library

Do we need explicit support? Can’t the consumer just use your adapter library?

This was added from the original removed ROADMAP.md: Instead, enable easy use of Guzzle and Requests via a new API, using Requests by default via Composer.

One could of course use the (relatively new adapter library) but the idea was to check for the existence of Requests and use the library, instead of the deprecated, not maintained File class. This way we could provide a nicer upgrade path without having a new dependency.

This check should be removed again in v2 and a PSR-18 client must be used.

• Improve mf2 support: [ENH] Consider better mf2 support #684

I would remove it from 1.9 milestone unless we have someone interested in working on this.

Fair enough. I will move it to 2.1.0 and we will see if someone complains about it.

@mblaney Any thoughts about this?

[jtojnar]

One could of course use the (relatively new adapter library) but the idea was to check for the existence of Requests and use the library, instead of the deprecated, not maintained File class. This way we could provide a nicer upgrade path without having a new dependency.

To be honest, I do not see the point of introducing whole another SimplePie\Http\Client instance, which would basically have to replicate your adapter anyway, just to remove it two releases later when we require PSR-18.

As I see it, the only benefit would be that consumers that already use Requests for something else could use a single unified HTTP implementation. But then there would still need to be a way to pass the same options, at which point it is no longer implicit. (I do not think there is any material difference for consumers in whether the adapter is part of SimplePie or a separate library.)

The original roadmap was created when there was no PSR-18 or even HTTPlug so the suggestion for Requests made sense then. But the ecosystem have moved, IMO.

[mblaney]

@jtojnar makes a good point @Art4, but if you want to do the extra steps on the roadmap that's fine with me. Otherwise I agree, remove anything that doesn't fit since you originally wrote it.

Is #837 ready to merge? Would be good to get open PRs in then decide if you're both ready for 1.9 or get 1.8.1 out before then.

[Art4]

@mblaney @jtojnar I'm totally with you both. I tried to implement PSR-18 in Requests directly (see WordPress/Requests#768) because this would be the best benefit for all. The library was then created from this PR, so the planned Requests implementation in SimplePie is obsolete. I will remove this issue from the roadmap.

For 1.9.0 we should merge #777 (and possible fixes from #826). And I recommend to merge #837 and deprecate the File class. (If #777 is merged I can start with the PR). This way we should release 1.9.0 really soon.

[jtojnar]

Is #837 ready to merge?

It is ready from my side, would still be good to get another set of eyes on it in case I missed something.

But as mentioned elsewhere, we need get PHPStan to at least level 8 to detect the strict_types errors. There are currently 129 unresolved issues for level 7 and another 55 for level 8. Those would need to be resolved for 1.9.0 if we want to be certain there are no regressions but that can be done later.

[Art4]

I moved the some issues like "deprecate the SimplePie\File class" into a new minor release as proposed in #850.