3 ms·

A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago. They were dropping support for older v

by donatj 4y ago

A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago. 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.

taftster 4y ago
I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV." 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.
shagie 4y ago
I am reminded of the libressl - 30 days in report. https://youtu.be/oM6S7FEUfkU?t=1073 https://youtu.be/oM6S7FEUfkU?t=1073 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.
- unity1001 4y ago
  > 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.

by donatj 4y ago

taftster 4y ago

I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV." 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.

shagie 4y ago

I am reminded of the libressl - 30 days in report. https://youtu.be/oM6S7FEUfkU?t=1073 https://youtu.be/oM6S7FEUfkU?t=1073 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.

unity1001 4y ago
> 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.