Proposal for limiting supported versions

[jrfnl]

At this time, the plugin is compatible with:

• PHP 5.4+, 7.x, and 8.x (Support for PHP v8 is available since v0.7.0)
• Composer 1.x and 2.x (Support for Composer v2 is available since v0.7.0)
• PHP_CodeSniffer 2.x and 3.x (Support for PHP_CodeSniffer v3 is available since v0.4.0)

These are very wide ranges and is a compatibility span of more than a decade for most of these.

With this ticket, I'd like to open the discussion for limiting the range of supported versions a little.

Proposal

I would like to propose to drop support for:

• Composer 1.x - done in PR Drop support for Composer v1.x #230 which will be included in v 1.1.0.
• PHP_CodeSniffer 2.x - done in PR Drop support for PHPCS 2.x #261 which will be included in v 1.2.0.
• PHP < 7.2

Planning

I propose that these changes be made once PHP_CodeSniffer 4.0 has been released (which also drops support for PHP < 7.2).

I also propose for these changes to be released as version 1.1.0 of the plugin.

Consequences

As users of this plugin will, by definition, be using Composer, we would not be leaving users behind as Composer will handle the version negotiation and can still install the 1.0.x version if necessary.

Based on the PHP version stats available via Packagist, the PHP version drop would affect 1.5% of the users of this plugin.

While not necessarily a precise representation of the users of this plugin, based on the PHP_CodeSniffer version stats available via Packagist, the PHP_CodeSniffer version drop would affect less than 0.2% of all potential users of this plugin.

Opinions ?

[fredden]

This sounds like a sensible change to me. For similar reasons (and considering the stability of this package), I would also be comfortable with adjusting the minimum supported PHP to 8.2 (https://www.php.net/supported-versions), and Composer to 2.6. Users who still require a version which works on older systems can use already-released versions of this package, and Composer is well placed to resolve this automatically.

Releasing this change as a minor version makes sense given the explanations above.

[jrfnl]

In my opinion, upping the minimum supported PHP version to anything beyond PHP 7.2 is not up for discussion.

This plugin hooks into PHP_CodeSniffer and is used by lots of external standards for PHP_CodeSniffer.

If the minimum PHP version for this plugin would no longer be in line with the minimum PHP version supported by PHP_CodeSniffer, it would mean that all users, including external standards, would either be limited to using the 1.0.x version or would need to up their minimum supported PHP version to 8.2.

I expect that the net effect of that would be that there will be an expectation that both the 1.0.x branch as well as 1.1+ branch would continue to be maintained, especially for essential bug fixes and for fixes related to new PHP versions, and I, for one, have no intention to start maintaining two branches for this plugin.

[Potherca]

I am in favor of trimming the tree. I agree with these perspectives:

Users who still require a version which works on older systems can use already-released versions of this package

and

the minimum PHP version for this plugin [should] be in line with the minimum PHP version supported by PHP_CodeSniffer

Should things be documented somewhere for future reference?

[jrfnl]

Should things be documented somewhere for future reference?

@Potherca I'd been thinking about how to document things like that (also for PHPCS and other projects). While not an official convention, how about adding a POLICIES.md file in the .github directory ?

Alternatively, it could probably be added to the CONTRIBUTING.md file.

On that note: the CONTRIBUTING.md file currently contains info on the release process of this package. In other projects, I generally have a release-checklist.md file (example) in the .github directory containing that kind of info, as that info is only relevant for maintainers, not so much for outside contributors.

Opinions ?

[Potherca]

I'd say, use the same refactor pattern generally used for code. Add a bit of text and move it to a separate file when the content grows beyond comfortable bounds. Linking to separate files for more details is always good, IMHO.

Something like this?

[jrfnl]

Relevant for this issue: Packagist will drop support for Composer 1.x per August 1st 2025.

https://blog.packagist.com/shutting-down-packagist-org-support-for-composer-1-x/

[jrfnl]

Just discussed this with @fredden - priority-wise:

• We could already drop support for Composer 1.x soon
• Drop support for PHPCS 2.x second - stats on Packagist show that usage is negligible by now
• Leave the PHP version drop until the PHPCS 4.x release.