> How much effort should a library maintainer expend to keep 5.x code in place? Based on the usage of the version and the support for it in large hosting/infra

> How much effort should a library maintainer expend to keep 5.x code in place? 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 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/ 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: https://jsonapi.org/format/ https://jsonapi.org/format/ > 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.