[question] would it be an option to lower the requirements to php7.1?

[c33s]

as its often not that easy to have the latest php version available on the server. it would be awesome to lower the requirements to php7.1 (even better would be 7.0).

debian ships in its current stable realease php7.0, of course with the sury repo it is not that difficult to install 7.2 but often it is only allowed to use the official php version which would be 7.0 currently.

do you really have so much need for the 7.2 features? wouldn't 7.1 be enough?

is it worth to block some/many users from using your lib (semver 2.0)?

[c33s]

also if i start using the lib now, i would like to use the new method names and don't learn the old ones.

[asgrim]

I think it's worth pointing out that this isn't just a language features thing, it's the support cost. The author maintains this library in his own free time, with no monetary support. To stretch this support over older versions of PHP just because you haven't upgraded is a really big ask IMO. Just my 2 cents, and I know not everyone really appreciates how much effort goes into these things, so just a friendly tip :)

[c33s]

my suggestion to target for 7.1 as minimum requirement version is because symfony requires php 7.1, which is a big influencer in the php scene and 7.1 really has some very good features (over 7.0).

it can need far less effort to only maintain a 3.x version which supports php 7.1 (so it catches every user of symfony4 components/framework, which will have a LTS until 11/2023 http://symfony.com/doc/current/contributing/community/releases.html) than force the users to switch over to the 2.x branch of this lib, which misses all the cool php7.0 and php7.1 features. users stuck there will still open issues/requests for the old 2.x branch which they simply need because they can't upgrade.

symfony have quite "hard" requirements, ideally it needs a webhost with php7.1 (cli & webserver), nodejs, yarn, ssh access and rsync. the problem is that so many hoster only provide php version up to 7.0 (but also php 5.4). last time i had a provider having php 7.1 on the webserver but only 7.0 on the cli. in my opinion this is hard enough and should not be made even harder by requireing php7.2

often customers want only a cheap host and not maintaining a whole server, so we are stuck with crap-hosts.

to still be able to develop on enterprise level we need such good libs as this one. well documented and well tested but useable with a major framework on a common host (common host is a little of a lie because the common hoster is still stuck with php7.0)

please understand that i don't demand that the version requirement is lowered, i simply asked if you may rethink your position.

[asgrim]

There's more to life than just Symfony. If we're talking versions in use, firstly, Jordi's latest post indicates 7.2 adaption is gathering pace quickly (see https://seld.be/notes/php-versions-stats-2018-1-edition). Ubuntu 18.04 LTS is generally a good indicator (or driver?) of what PHP version to use as it's such a common distro - and they're on 7.2.

But I highlighted already that my point is not about "what version of PHP are most people using" it is a matter of "how much of @nikolaposa 's free time does he want to give up to support users". This is open source. No-one is paid here. Perhaps if you're working for an enterprise that has such a need of this on older PHP versions, you might consider hiring @nikolaposa to support older PHP versions. Otherwise, and I don't want to speak for him, but I think the answer is no.

So going back to your original post:

is it worth to block some/many users from using your lib (semver 2.0)?

Yes it is worth it because then @nikolaposa maintains his quality of work/life balance, has better mental health, more time with his family/friends.

From my perspective: this library is excellent. It's not the library author's fault if you're stuck on an older PHP version, so it's really unfair to ask him to give up HIS FREE TIME because your company who doesn't pay a single penny/cent/etc can continue digging their heels in.

[nikolaposa]

@asgrim Thank you for you kind words, I could not have formulated that side of the story better.

@c33s Thank you for expressing your friendly opinion through this issue, I somewhat understand your point. I feel like I need to explain the intents behind my decision, instead of being a silent observer of this conversation.

Don't get me wrong, I haven't set 7.2 requirements just because cool kids do it. There's a saying in my country: what you can do today do not leave for tomorrow. After a long time I decided to upgrade some things in this library (very irresponsible on my end, I'm a lazy maintainer, I admit it), and I wanted to do as many things so that I don't have to worry for a while about making major changes except for bug fixes.

If you take a look at PHPs calendar (http://php.net/supported-versions.php), you will see that 7.1 will be actively supported just a few more months, which is another thing that goes in favor of my thinking.

PHP language evolves, but it cannot evolve if folks are stuck on older PHP versions, I hope you agree with that. One way to raise awareness and stimulate them upgrading is through this kind of initiatives.

[kelunik]

@nikolaposa I just reviewed the code and couldn't find a single PHP 7.2 feature used. Did I miss something or could the requirement be lowered without changing anything in the library?

[nikolaposa]

@kelunik Yes, it can be lowered for sure. The question is whether I should do it and then not being able to use latest features if I happen to need them for some future improvements.

IMO setting version requirement is not only about complying with the minimum language functionality that you're using, but more of being future-compatible in terms of having the opportunity to use latest features without needing to bump major version.

[asgrim]

Yes: support scope would be changed. Not sure what is not clear here: supporting more versions of PHP means more of maintainers time. Simple. By asking for more versions of PHP to be supported, you are asking the author to give up potentially more of their own free time. It is no-one else's decision except the maintainer's. Remember: this is open source, if you don't like the way a project is run, fork it and support PHP 7.1 yourself, but don't expect this, it is totally unfair to expect more of @nikolaposa time than he already dedicates if he doesn't want to: even if it IS technically possible. If he wants to do it, he can and and will.

On Thu, 17 May 2018, 08:50 Niklas Keller, notifications@github.com wrote:

@nikolaposa https://github.com/nikolaposa I just reviewed the code and couldn't find a single PHP 7.2 feature used. Did I miss something or could the requirement be lowered without changing anything in the library?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nikolaposa/version/issues/19#issuecomment-389777191, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeSEakpR2qIiXOXjWeYGjaKWn7fnrAHks5tzSvEgaJpZM4T3fwv .

[kelunik]

@asgrim Of course, we all got that I think.

@nikolaposa You can raise the minimum version requirement at any time without releasing a new major version. I personally don't care, I was just trying to help.

[nikolaposa]

You can raise the minimum version requirement at any time without releasing a new major version. I personally don't care, I was just trying to help.

@kelunik I'm still not sure whether raising minimum version requirement should be considered BC break or not. Opinions vary.

[nikolaposa]

@c33s Here's what I did:

1. released 3.0.2 with a loosen PHP requirement (^7.1) so that folks using that PHP version can take advantage of features and improvements that were introduced in latest major version of my library
2. 3.0.x branch is immediately discontinued and will serve only for bug fixes; new functionalities and improvements will be available on 3.1.x