Php_codesniffer: EOL PHP 5.4 and 5.5?

[truls1502]

I was wondering, do you want me to create a PR to remove PHP 5.4 and 5.5 since they are EOL (End of Life) or are you keeping these PHP versions for any reason?

EOL of the versions are stated on http://php.net/supported-versions.php

[jrfnl]

Duplicate of https://github.com/squizlabs/PHP_CodeSniffer/issues/1244

For PHPCS 3.x the answer will be "no".
See: https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.0.0a1

Not sure what the minimum PHP will be for PHPCS 4.x, but development on that hasn't started yet AFAIK.

Oh and PHP 5.6 and 7.0 will be EOL within a few months a well :wink:

[Majkl578]

@jrfnl That reasoning is over 2 years old.

Bumping PHP versions in minor releases is not a BC break, so it's a huge :+1: from me. Should be bumped to ^7.1 directly for PHPCS 3.4.

[gsherwood]

That reasoning is over 2 years old.

It still stands. I wont be reviewing the version requirements until version 4.

Bumping PHP versions in minor releases is not a BC break

A minor version upgrade that stops the product working for anyone using an older PHP version feels like one of the biggest BC breaks I could possible do. I did this for HHVM because I knew I couldn't support HHVM going forward and I wasn't going to be releasing version 4 soon enough to break BC for it. But it's not like I'm going to find maintaining support for older PHP versions hard, so I'm not going to even consider dropping support for them until version 4.

Also note that I haven't even started work on version 4, so I'll be supporting the PHP versions I've committed to for quite some time.

[Majkl578]

A minor version upgrade that stops the product working for anyone using an older PHP version feels like one of the biggest BC breaks I could possible do.

No. Minor versions are feature releases. Legacy users stay on legacy pach versions.
This topic has been discussed many times already, no need to repeat here. Please read the Doctrine article about bumping PHP requirement - _Why dropping PHP support in a minor version is not a BC break_ section.

so I'll be supporting the PHP versions I've committed to for quite some time.

Two words only: _have fun_ (or _good luck_?).

[truls1502]

Interested what it is written on Doctrine article about bumping PHP requirement - _Why dropping PHP support in a minor version is not a BC break_ section.
Copied the section part:

Why dropping PHP support in a minor version is not a BC break

One question we frequently hear is, "isn't dropping support for a PHP version a BC break"? In a nutshell, no. A BC break happens when there is an incompatible change that your package manager can't handle. For example, changing a method signature in a minor version is a no-go, since the composer version constraints mentioned above assume any minor upgrade can safely be used.
However, when we drop support for an older version of PHP, composer will not consider the new version if the PHP version requirement is no longer fulfilled. Thus, you won't end up with a fatal error due to a wrong method signature, you just won't get the new version.

Of course, you decide what you want to do. I just was asking if you needed help regarding remove the PHP versions, I am happy to help you :)

[jrfnl]

A BC break happens when there is an incompatible change that your package manager can't handle.

This presumes that everyone uses a package manager to manage PHPCS, but as - just like PHPUnit and numerous other tools - PHPCS is basic dev tooling, there are plenty of people who use the PHAR, the PEAR version or a git clone instead. Or use versions which are shipped with their IDE or CI manager over which they may have little to no control.

So, the reasoning Doctrine uses, while valid in their use-case, does not necessarily apply to PHPCS.

[truls1502]

Ok, @jrfnl - Thank you for the explanation :)

[vladyslavstartsev]

@jrfnl if people use

people who use the PHAR, the PEAR version or a git clone instead

then they lock them selfs to some version, for example 3.3.2.
And if you use one of those and lock to some of those, then you can't randomly update things, isn't it works like that?

IDE or CI manager

then people just made dumb decision to depend on IDE or CI manager that keeps them outdated, I mean there should be a way to use newer version of software.

Really the arguments that you have provided doesn't makes sense, at least for me

If you can't control things that you depend on you can't control your code.

BTW, what can be done is writing a message in console that it is better to use current stable php version
the code should be easy, something like this

if (PHP_VERSION_ID < 70200) {
    //write the message
}

ok, at least you can make mentioning about it in
README.md and add this issue to PHPCS v4 Development project board

[vladyslavstartsev]

@gsherwood @jrfnl

you can officially support or just mention, that you can use https://github.com/cytopia/docker-phpcs this way you can do this ( drop EOL PHP support)

[jrfnl]

@vladyslavstartsev I'm not sure I understand your point. The current minimum PHP version does not inhibit installing PHPCS on higher PHP versions. PHPCS runs fine on PHP 7.4 for that matter.

The docker image you mention above is just one way you can use to run PHPCS, but completely ignores all the other install methods which are currently still supported.

If it's about external standards: there's nothing stopping an external standard from setting a minimum PHP version which is higher than the minimum PHP version supported by PHPCS.

FYI: A look at the initial commits for PHPCS 4.x shows that the minimum version for that will be PHP 7.0, but this may still change.