Related: open source devs fret if a library hasn't been updated in the last month, even if it is feature complete with no bugs.
I personally support every version of my projects.
My goal is not to minimize the effort to myself but to facilitate the use of my software.
If, however, I saw a statement at the top of the README that said:
"Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed"
then I would feel very confident.
Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."
If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020.
On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.)
Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)
In my experience old games often work better in proton/wine than in Win 11.
My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.
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.
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.
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.
I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases.
I think people might be:
1. Implicitly assuming that all nontrivial code has bugs, and 2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.
The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.
I think what you are saying is simply FUD when taken as a blanket statement.
But thanks for trying anyways.
Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day.
The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security.
> Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.
You didn't specify the language or library.
Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities.
The mathjs package in NPM, for example, has had tons of vulnerabilities[1].
NPM system is security abomination I agree. But I am not using it. I look at things from my own perspective. If 90% of the world programmers are bound to NPM ecosystem (doubt it) it is their problem. Not mine. I do not "import" half of the Internet for my "hello worlds".
This is how the Gods do programming :)
Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.
Thing is, even if there are no known bugs, having rare updates means if I do find a new bug it’s less likely to get addressed quickly.
Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind.
Everything continuously improves: cars, bicycles, windows, houses, refridgerators, tv, etc, etc.
We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.
Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).