But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained?
Just release when there's something to release.
Just release when there's something to release.
People seem to know that. Developers sometimes do not.
There is no software without bugs in the same sense that there exists no hardware that cannot fail. But you can create software that is so close to perfect that hardware failures outnumber software failures 100:1, so there is no point in pursuing perfection any further.
mkdir(1) is also not typical. Excluding the copyright header comment, it's so short that it fits entirely on one screen. If I ran into a bug, I could probably find it and fix it (or write my own version) in about 3 minutes.
It is indeed possible to "create software that is so close to perfect that hardware failures outnumber software failures 100:1", but it's so time-consuming that almost nobody ever does it.
Version 1.0.1 of a free mind-mapping app may be good and useful software, but I can virtually guarantee it has bugs. I doubt even the author would claim it's only at 1.0.1 because "there is no point in pursuing perfection any further".
However, I think you're approaching this from the wrong way. The most important thing about sqlite isn't the amount of manhours put into it, but the millions upon millions of manhours that have been saved because the product works so unbelievably well.
sqlite is the exception, and this is because the people involved in it really care about quality. Our software engineering culture has a lot to learn from the success of sqlite.
296 lines in the main .c file, without counting the headers and helper functions: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...
Really? A running 3 years out-of-date sqlite install?
Methinks some hackers smell chum in the water. XSS, remote code execution, priviledge escalation, directory traversal... and for most of these, we even have choices on how to attack! Plenty of overflow attacks involved here. Where are the idiot script kiddies when you need them to demo how this ignorance hurts?
And once in to your sql database, I wonder where else we can pivot...
Remember how shellshock shook the world, because the software bedrock was actually insecure? Yeah... your old, "stable" stuff has had holes the entire time.
Stay current. If your OS makes that a challenge, ditch it for a better one.
Or bugfree for the use cases of it's users (how many or few there may be).
Edit: here you have the source code for the "small" ls utility: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c. Yes, over 5000 lines.
Software cannot be perfect but this doesn't mean that software needs to be shoddy. sqlite is a complex product and it has orders of magnitude fewer bugs than other projects of similar complexity.
It is factually, observably, possible to create software that is very close to perfect, it just takes a lot of hard work. Software has a reputation for being buggy not because it's impossible to write flawless software, but because most software is really poorly written.
[1] https://github.com/Bluerise/OpenBSD-src/blob/master/bin/ls/l... [2] cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/ls/ls.c?rev=1.75.4.1 [3] https://github.com/freebsd/freebsd/blob/master/bin/ls/ls.c
If someone opens an issue, will it get addressed quickly? That's what users care about.
But then we have the other side, releasing update after update without fixing or responding to common issues. That is quite damaging as well.
It's so true that you never ever see people using decade old versions of software, right?
Users care that their shit works, that's it.
Exactly, so when that forced OS update broke the software it is kind of nice to know that someone is still around to fix it.
This duality of updates is why people avoid updating.
This emphatically does not work very well for big projects. The problem is human pyschology and the unreliability of all effort estimation processes (in software development). Once people get used to the idea that "well, we'll just postpone the release a little bit" then it eventually becomes a routine thing and for popular projects there's always someone who has a good reason that their particular feature should make it in before the release. (Because who knows when the next release will be?)
The Linux kernel and the C++ ISO standards committee have got this EXACTLY right (since C++11). Predictable releases means:
a) you don't need to rush anything particularly because you know there'll be a new release in N months.
b) any incidental small (not-worthy-of-a-release) bugs get fixed in the interim.
c) downstreams can plan based on when your next release is going to happen.
Predictability is a huge deal and IMO it's incredibly underappreciated just how much it matters. Even if it meant a 10% or 20% 'efficiency' loss (on some metric) I would personally still consider it a win.
For an example of not doing it this way, look at C++ pre-2011 and perhaps also ECMAScript pre-2015. (This is also rampant is development, though no public examples come to mind right now. I'm sure some other commenter can supply some. It's so bad that it can in fact kill projects.)
EDIT: I forgot to mention: Regular updates also means that the "consumer" must get into the practice of regularly applying updates... and will thus become forced to get better at doing that. Ideally to the point of having completely automated updates.
I do find projects like Dwarf Fortress very charming in that there's an endless supply of new things to look forward to.
Software can only be as correct and complete as its specification. If that is a moving target, oops!