Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.
Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.
That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying "I'm not going to deal with something that had its last release nearly 4 years ago."
> That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying
Yes it should. Its not 'some' provider. Its providerS. A gigantic part of the web lives on such large hosts. AWS and similar ecosystems constitute a small part of the web. This is not saying that the former is low traffic but large in size compared to AWS et al. There is similar traffic and user activity going on in both ecosystems.
You can easily 'deprecate' something and spend millions of dollars man-hours in upgrading your stack as a larger startup which uses AWS. But millions of small businesses, individuals who rely on Open Source software and such hosting providers won't have the money or time to jump through such upgrade hoops 'just because'. It is 'just because' for the simple fact that a lot of such version hops we do in Open Source software development do not bring much to the end users. And they will not appreciate their businesses getting hampered trying to go through upgrade hoops which they have never asked for.
An alternate approach to this is saying 'f*k you' to those people and doing Open Source for the sake of software development itself, without caring about end users. That would also work - but only for those who develop Open Source and who have the time to keep it updated. The general public would just move on from Open Source and start using reliable private service providers that don't break their businesses every other year.
Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
Note that the FOSS approach to "but it doesn't support the old version that I'm running" has been "don't upgrade or fork it and maintain it yourself." It's the flip side of https://boyter.org/posts/the-three-f-s-of-open-source/ ( https://news.ycombinator.com/item?id=32591265 ).
I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.
Based on the usage of the version and the support for it in large hosting/infra providers.
> Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
Breaking backwards compatibility is practically always bad. You do it once. You do it twice. By the third time it does not matter because a large part of your users would have moved on to some other stack by the second time.
> If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
These must be seen as ecosystems. The ecosystem would slowly move to a higher version over the span of 2-3 years starting from the point when a version starts nearing its EOL. And the users upgrade slowly on their end.
> https://boyter.org/posts/the-three-f-s-of-open-source/
Using the same language in the article: The users would say one single F word to such a project, without the project maintainers ever hearing about it, and silently move on to some project that is not so self-indulgent and so irreverent towards its users. Nobody has the time to jump through hoops to keep their business running on Open SOurce, less suffer such arrogant sh*t.
Such an attidude is only workable if the project is a hobby one, does not aim to gather ANY kind of community/userbase, does not aim to do any impact.
> I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.
I would recommend that you prioritize your users and backwards compatibility in that order. The moment your users start trusting your project that it will not break their software, they will start upgrading easily and adoption and retention will get boosted.
JSON API spec's 'only add, never deprecate' approach is the holy grail to chase:
> New versions of JSON:API will always be backwards compatible using a never remove, only add strategy. Additions can be proposed in our discussion forum.
e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly.
This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.
They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.