Drop php support below 5.6?

burzum commented 7 years ago

Just see http://php.net/supported-versions.php

avalanche123 commented 7 years ago

👍

robfrawley commented 7 years ago

:+1:

romainneutron commented 7 years ago

What value does it bring to drop support? Let's think about the industry. PHP 5 is still widely used. Encouraging migrating to PHP7 does not mean dropping support of PHP5

As supporting old PHP versions is not a pain at the moment, and updating the dependency, I'm 👎 at the moment

burzum commented 7 years ago

@romainneutron php 5.6 is OK but already EOL. It will receive support until 18th December 2018. Nobody said to drop 5.6 yet. But I don't see a reason to stick to old, unsupported versions.

nicolas-grekas commented 7 years ago

:-1: also, unless you bump the major version number. Having this strict policy is one of the key success factor in Symfony - users know they can keep up to date within the same major version without being forced to change their infra. For sure it adds some burden on the maintainers yet it's really nice to users - and I think every maintainer should and wants to be nice to users, so the burden is worth it.

burzum commented 7 years ago

With all the upcoming changes just bump the version? Apply fixes that work for the 0.6.x version and make tests work and tag a new 0.6.x. After that bump to 0.7.0 or even 1.0.0 (if you want to go for semver) and drop php support for versions below 5.6.

romainneutron commented 7 years ago

Well @burzum ,

My point is that the industry (people working with PHP) are still using PHP 5 a lot. Ubuntu LTS still distribute PHP 5, Symfony LTS are still supporting PHP 5. For instance, CakePHP seems to support PHP 5.5 in its latest release too.

Imagine is a high quality library that helps its users, removing PHP 5 support will break imagine usage for lots of users. From the experience we have in Symfony, the backward compatibility promise is very important, and such changes should be considered very carefully.

I'd rather be in favor of working towards a Imagine 1.0.0 version and drop PHP 5.3 and 5.4 in a version 2, and wait for PHP 7 wide adoption to drop PHP 5 support in a version 3.

I don't understand your point, I don't understand why you don't want to support PHP 5 anymore. Please let me know.

robfrawley commented 7 years ago

PHP 5 has reached EOL ("end of life"), and that is reason enough for me. It is the responsibility of the community as a whole to help move people along to newer PHP versions and to avoid the slow move to PHP 5 and some of its minor releases. The slow adoption was facilitated by a lack of demand from users, due in part to a lack of higher requirements from the projects they used.

Additionally, the Packagist statistics show that every version of PHP is declining in usage except for PHP 7.x, which was 1% behind surpassing PHP 5.6's usage percentage back in November of 2015. [1] PHP 7.x is faster for users and offers a better experience for developers. Even PHP 5.6 would offer a great number of improvements and provide quite a few new language features.

A move from PHP 5.3 to 5.6 includes:

Short array syntax (I'm so tired of using array())
Variadic functions
Array unpacking
use function and const
finally blocks in exception handling
Class name resolution via ::class
Support for traits
Function array dereferencing
Closures with $this context
Class member access on instantiation (ie (new Foo)->bar())
Generators

And a move all the way to PHP 7.x includes:

Scalar type declarations
Return type declarations
Null coalescing operator
Spaceship operator
Array constants using define
Anonymous classes
Generator delegation

As for version naming, according to Semvar "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." [2] Additionally, the current release won't somehow disappear. We aren't considering the PHP version bump for the 0.6 series, but instead for our next major release. @nicolas-grekas Where did you get the idea we wouldn't bump the library version?

The 0.6 series will remain available (it's not like it'll be purged from Packagist) and of course, it will be maintained for some time with both bug fixes and security fixes; I'd highly recommend we continue to accept reasonable feature requests as well. The new code can (depending on demand) be backported to some extent, as well. But in the context of our next major release, I remain :+1: for a big PHP minimum version requirement bump. Some projects that use this library have already decided to do so in their next major release, including liip/imagine-bundle.

robfrawley commented 7 years ago

I do believe that we should treat this as a 1.0 release when we bump the PHP requirements, not a 0.7, regardless of the semvar recommendations.

romainneutron commented 7 years ago

@robfrawley IIUC, your point is to drop support of PHP 5 because it EOL'ed. I'm sorry, this is not enough, and you did not answer my arguments. I discussed yours, I would like a dialogue instead of being stucked in front of stubborn arguments.

Do you know Imagine's release history? There's not support for n and n - 1 branches, at the moment, there is only maintenance on the current branch. Maintaining a n - 1 branch for security and bug fix is huge work

burzum commented 7 years ago

I would like a dialogue instead of being stucked in front of stubborn arguments.

Calling other peoples arguments and concerns "stubborn" is not what I would call having a "dialog". It sounds arrogant the best and doesn't add value to the discussion.

I agree with @robfrawley and my suggestion would be to stabilise 0.6, get the tests working again, and fix the bugs that are reported. No new feature additions.

At the same time start working on a 1.0 branch that drops 5.6 support and goes directly to 7. It is not like that the 0.6 branch is unusable. It worked fine for years and even within the last ~2 years where almost no support at all was present. So I doubt anyone will complain if there is a 0.6 version that works for php5 and a modern version that gets new features.

While I agree that software development should be evolution and not revolution I don't see a revolution happen with this proposal because a working and usable solution for people stuck to older php versions will be still available. If "the industry" as you call it wants to stick to old versions fine, but then you have to live with some drawbacks, the same as when you decide to go for bleeding edge versions. I've worked on both kinds of projects before.

You can remove me as a collaborator from the repo by the way, looks like you guys have more time you can and want voluntary spend on it. It's enough for me that it looks like development is going on again now. :)

robfrawley commented 7 years ago

@romainneutron I simply expressed my opinion on the matter. Can we entertain the idea of being respectful of others?

garak commented 7 years ago

+1 for dropping support for 5.* and go for php7. We need an example from major libraries to take such steps. Of course, if someone is still on an old php version, they can continue using older versions of this library. Also, if there are major security issues, a new minor release for 0.6 can be released.

By the way: Ubuntu current LTS ships with php7