Behat: Drop support for obsolete PHP versions

[Sam-Burns]

I suggest dropping support for PHP 5.3 and 5.4. Also, maybe update the Github and Packagist repository descriptions.

Also - reasonable people may differ on this point - but I think you should drop support for PHP 5.5 as well, as it is not subject to routine bugfixing anymore. If you don't like that idea, maybe leave it till July when security support stops.

[Sam-Burns]

Ref https://github.com/Behat/Behat/pull/822

[stof]

Well, given that people are using Behat to test their libraries, dropping support for PHP means forbidding them to test their package on these versions too.

So I would not drop support just for the sake of dropping support. What is the actual benefit you will see here ?

[Taluu]

This is quite different here. Waht is proposed here is just to stop supporting these versions (we've got to move on eventually, otherwise, it's gonna be php4 all over again...), as in "It may work with php 5.3, it may not work".

What are the actual benefits ? for starters, the features brought by php 5.4+ (such as the traits, the major speed improvments (huuum php7...), splat operators, ...) which could be (I am saying _could be_) useful.

Also, it may also be used as a kind of an example of libraries promotong newer versions of php, and maybe encouraging to upgrade there. But this may require a version bump though (that's what Symfony did with Symfony 2, promoting php 5.3 instead of php 5.2 as it was designed for at the beginning).

[stof]

speed improvements is already there, as you can already run PHP 7 in your projects. The fact that the min version is PHP 5.3 does not mean you cannot use PHP 7. And this will not be a benefit for Behat itself (it does not change the maintenance load to have it faster when using PHP 7).
Changing the composer requirement means that people running a composer update on 5.3 will get old releases instead of the latest. So this is not a "it may work". It is a "we don't let you try"

[stof]

And regarding traits, I cannot thing of places in the Behat codebase which would use them, even if the min requirement was 5.4 (I don't use traits much to be honest).

[Taluu]

Maybe, but still,, some features that could be used can't be actually used (Traits and all). I do not have any examples in mind in Behat source code, but I think this argument is as valid as any other. IMHO, Behat 3 should have at least been developped with 5.4 (or 5.5, as it was the stable at the time).

The fact that the versions below 5.5 are not maintained anymore by the php team (even though that some LTS distribution are usually backporting the fixes) is still here. May I remind that php 5.2 (not going to php4, mind you...) is still used by a small percentage ? One the few reasons why is because 3rd party libraries are still maintaining on these versions (well now it's php 5.3). We should really think of killing these...

Remember the go-php5 and the now go-php7 movements...

Yes, this is irrelevant but still. As in the semantic versionning, it leaving the version bump to the developper if such an upgrade is made, even if nothing is changing in between (just the requirement), I still think it's okay to bump the requirement.

[stof]

Well, what I mean is that Behat dropping support for older PHP versions means that any project tested through Behat also has to drop it (as they won't be able to test their project anymore unless they use an outdated version of Behat, which is not good either). And I don't think I can have stats on the versions used by projects using Behat.

[rajeshtaneja]

+1 for _not_ dropping support for older PHP versions. We support php 5.4.4+ versions for our software and if support is dropped for older versions then we won't be able to run behat with older versions.

PHP version support should only be dropped if it's a hurdle in future enhancements, and not because it's old.

[ciaranmcnulty]

@rajeshtaneja it's not actually that dramatic; you'd still be able to use Behat. You'd just not be able to upgrade to newer versions

[rajeshtaneja]

@ciaranmcnulty, I don't agree with that.

Assume 3.x don't support php5.4, Now if you want to run Behat on your project to ensure it works with php5.4 and php 7, thes how will you do it ?

Are you going to run Behat 2.55 for php 5.4 and Behat 3.x with php7 ? If yes, then you need to maintain 2 different branches of your contexts/steps, to run tests, as 3.0 is not BC.

[shrikeh]

As 5.4 is EOL, I'm quite fine with this. If you need to support 5.4, you
can do some magic in your build env. The reason composer uses composer.json
is a default value that can be overridden as a CLI argument; you could
create a separate JSON file called php54-support.json with the versions you
need, and have your build vendor off that in a matrix.

Barney Hanlon

http://about.me/barneyhanlon
PHP Software Engineer
[phone]

On 25 Jan 2016, at 07:49, Rajesh Taneja [email protected] wrote:

@ciaranmcnulty https://github.com/ciaranmcnulty, I don't agree with that.

Assume 3.x don't support php5.4, Now if you want to run Behat on your
project to ensure it works with php5.4 and php 7, the how will you do it ?

Are you going to run Behat 2.55 for php 5.4 and Behat 3.x with php7 ? If
yes, then you need to maintain 2 different branches of your contexts/steps,
to run tests, as 3.0 is not BC.

—
Reply to this email directly or view it on GitHub
https://github.com/Behat/Behat/issues/821#issuecomment-174429909.

[Sam-Burns]

@rajeshtaneja Behat 3.0 will always work for PHP 5.3 and up - no need to worry about that. You can even pin your repo to 3.*.* and run Composer using any given PHP version - it will install 3.0.x when run in PHP 5.4 and 3.1.x when run in PHP 7. There is no need for you to have two different test suites.

The two arguments here are about responsibility and the internal codebase. First, we should be encouraging users relying on obsolete versions of PHP with no security support to upgrade, and other major projects like Symfony, PHPUnit, Zend etc. are trying to show leadership in encouraging users (and therefore their hosting services) to upgrade. Secondly, writing the codebase in PHP 5.3 is becoming annoying, and we've seen builds being broken because of use of short array syntax years after it was invented.

3.0 will continue to work in PHP 5.4 forever - just carry on using the version you're using until you can upgrade. But at some point we have to drop support for obsolete language versions, and 18 months after security support for 5.4 ended is already a little too late IMO.

[everzet]

Here are my thoughts on this one after reflecting on it for some time.

Supporting outdated versions of PHP is technically free for us - it does not require additional effort (yet?) or care at the moment - it is just Travis running the test builds and in most cases when tests get broken on 5.3 or 5.4, they also get broken on 5.6 (which is not EOL). So from purely practical perspective, there is absolutely no reason to drop support for 5.3 and 5.4.

That leaves us with the political reason alone - promote abandoning of non-supported language versions for projects. And event though I do understand that driver, I don't think it's either necessary, nor effective as Behat usually is not a runtime, but pure development dependency. Pushing Symfony or other major libraries to drop support for older versions of PHP is a much more effective argument for upgrade.

With those two points in mind, I don't feel comfortable dropping support for versions that are technically supported in the minor version. I do, however, support drop of EOL PHP versions in the next major version of Behat and that is most-likely what will happen when we get to 4.0. But before that, I don't think that benefits (upgrade promotion) outweigh costs (possible confusion and BC argument).