4 ms·

> If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library Its not. Large Linux distribut

> If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library 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.

shagie 4y ago
So what version of PHP are we talking about? https://www.php.net/supported-versions.php https://www.php.net/supported-versions.php and https://www.php.net/eol.php https://www.php.net/eol.php 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."
- unity1001 4y ago
  7.4 is supported on focal until 2025 for example. Centos has its own LTS and supported versions and so on. > 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.
  - shagie 4y ago
    How much effort should a library maintainer expend to keep 5.x code in place? 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 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://boyter.org/posts/the-three-f-s-of-open-source/ ( https://news.ycombinator.com/item?id=32591265 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.
    - unity1001 4y ago
      > 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.

shagie 4y ago

So what version of PHP are we talking about? https://www.php.net/supported-versions.php https://www.php.net/supported-versions.php and https://www.php.net/eol.php https://www.php.net/eol.php 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."

unity1001 4y ago
7.4 is supported on focal until 2025 for example. Centos has its own LTS and supported versions and so on. > 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.
- shagie 4y ago
  How much effort should a library maintainer expend to keep 5.x code in place? 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 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://boyter.org/posts/the-three-f-s-of-open-source/ ( https://news.ycombinator.com/item?id=32591265 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.
  - unity1001 4y ago
    > 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.