I actually don't think there is anything wrong with having time-based releases, and putting very little content in some of them. If you only fix one bug in a quarterly/bi-annual release and tweak some docs, because that's all that's needed, you have still fixed an issue for somebody, and demonstrated to all of your other users that you are still keeping your commitments, and there for them if they need you.
Just release when there's something to release.
People seem to know that. Developers sometimes do not.
But then we have the other side, releasing update after update without fixing or responding to common issues. That is quite damaging as well.
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!
Following that logic, a software cannot possibly be completed - It can be either in development or dead. Which would mean you either have a budget of time, money and resources for constant maintenance of your software - or you might not write that software at all. Repeat that for every new piece of software you want to write.
The problem is that this is impossible to do for hobbyist authors, so we would lose a large amount of free or open-source software currently available.
He offloaded the whole project onto another team (who mostly backported fixes) that kept it going until early 2016. The rest of us were already in Linux 4.X territory by then.
If you cant maintain it, you can pay someone.
Or, thanks to Github, lets talk about letting the code-literate userbase sort it out themselves. Assuming they care enough.
Or, we could pivot this discussion to the "evils of Capitalism" and whatnot since that userbase probably needs to eat.
"Trained" is the word I have thought of many times as well. It is perplexing to see people wanting updates.
It is possible to write finished programs that are bug-free[FN1]. But when eternal rounds of patching becomes a religion, what sort of standard are developers promoting? Every program is expected to have security holes that will need to be patched? What about not releasing software unless it is safe to begin with? Why does a liability need to be created? Solve the problems before the software is released. Not after. Can't solve them? Then do not release.
Automatic updates are also a security hazard in the same way as "antivirus", which also trained users to want updates. It is a backdoor that users are advised to leave open.
FN1. Inevitably there will be the HN commenter who repeats some meme that says all software has bugs. True perhaps if we forget about Ada and the world outside of MS Windows, but are all the bugs major ones? Consider the stuff you find at http://cr.yp.to. Or many of the small UNIX utilities. I could name more selected examples. There is such a thing as finished software. With no major bugs. That does not need constant updates.
The updates that are causing the fever are not just "bugfixes", they are the current state of living software--always expanding and improving (at least in intent). The fact users see software that hasn't been updated as dead is a reflection of their learned expectations. And they are correct, it likely is dead in the "no longer improving as my other software is" sense.
The real issue I have is how shitty most update processes are. Thanks for rebooting my PC Win 10, yes Sublime Text, please tell me again in a dialog that there is an update, etc. Some apps have done much better here like Chrome and Discord, but it is not an easy thing to build.
The general attitude (both on HN and elsewhere) is that if any security update exists for a product you use then you are a complete moron not to update it immediately. There is virtually no acknowledgment of any nuance on the topic in my experience.
There is no such thing as finished software.
The size of a bug is in the eye of the beholder.
Sorry for the Shellshock.
Edit, took me two seconds to find: https://news.ycombinator.com/item?id=502651. Just as response to http://cr.yp.to/djbdns/guarantee.html
I saw a study done on github where the author wanted to know what languages had the smallest open bug count, and found unexpectedly that c and c++, which are notoriously bug inducing languages, had some of the lowest bug rates of all the languages. His conclusion was that the low bug count was actually due to the languages being used for foudational work, libraries and drivers and such, basically reaffirming the 'many eyes make shallow bugs' adage.
The better metric for if software is no longer being maintained is how responsive is the maintainer to their mailing list/support channel. Regularly seeing requests going unanswered is also likely to show that any updates that happen are also likely ignoring actual user needs.
While some may think I have misinterpreted the blog author (and I acknowledge this is a valid response), I still think that bug or nondescript "security fixes" is a powerful, fear-based mechanism to compel users to allow updates -- of any kind. And it therefore relevant to any discussion of "updates". Especially when it is common for these bug or "security fixes" to be inextricably mixed with non-security items such as "features" in such a way that the user must except the "whole hog", perhaps in some way similar to "omnibus legislation" in the US Congress.
I respect everyone's opinions whether you agree with me or not. I am just happy to see that some users may be thinking about "updates" and what they really are instead of blindly accepting them without ever pausing to think.
From my perspective every new "feature" that adds code is also introducing a new potential for a bug or security issue. I want programs and systems to get smaller not larger.
The most important thing is that I need to be reassured that if a major bug is discovered in the software I’m using, then it will be fixed. How can I be sure of that? The absolutely simplest way is if the software releases regular updates with very small changes. It’s a heartbeat to let people know there is someone that will solve the future problem.
I don’t even need to install these updates! They are mostly symbolic, that doesn’t make them irrelevant.
More likely, development simply slows down because the maintainer got lazy, moved on to other interests, or doesn't have time for other reasons. Users don't like this and they are right to worry that the maintainer may be unresponsive or that the software will not be quickly patched in the event of a security vulnerability being discovered because the software is not actively maintained.
Your software is not complete. It is merely functional. In fact, it may not even be functional, as the rest of the world moves on without you and your code rots away.
To my knowledge, they all still do exactly what I made them to do. Are there things I would like to add to some of them if I had unlimited time? Yes. Does not having time to do that mean that they've stopped doing what they were designed to do? No.
The only time I can see an argument for frequent updates being required (as opposed to a bonus) is for software with direct dependencies on other things. youtube-dl, for example, or the NTDS.dit-extracting functionality in Impacket are good examples of this - they work directly with content that may change at any time, so someone needs to make sure they're compatible with the current versions of that content.
Also they know when and why to update stuff they work on, thus i never happens at an inopportune time. Nor do they find themselves having to wrangle the new dependency kudzu they created, because for them it built up over time.
Besides any moderately complex software will probably have enough bugs to require updates now & then for years, even if no new features or added. Not only bugs but often the underlying platform changes/breaks, needing workarounds or rebuilds.
E.g. https://github.com/dardoria/uuid a library to generate UUIDs: once it fulfills the spec properly, it's essentially done. This particular example could contain a bug, of course, but the principle stands.
Another subtle difference is that on Linux platforms, you have more control over when/how to update, as well as visibility into exactly what is updating. I'm sure it's visible on other platforms, but I don't have to worry about rebooting my machine and having to wait 2 hours for it to come up.
Perhaps another point worth mentioning, LTS versions of Linux distros (Debian stable, or Ubuntu LTS versions) mainly get security patches, and, optionally, back ported software. That makes your OS stack super stable!
I'd put kernel upgrades into a different bucket... but most users don't need to update their kernel on a daily or even yearly basis except for security patches.
Great point about coreutils too! No need to update ls and grep...
This is something new for Microsoft: Usually they won't break their own old software with updates, they are known for keeping up backwards compatibility at all costs.
It really isn't. Thirteen years ago: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
If you ask the users about it, they don't even know why they want these updates. Is there a feature they are missing?
New things are fun. Maybe there'll be a feature I don't know I'm missing until I see it. I'm hankering for you to amaze me and fix all my problems. Be my Holy Grail of (text editing, browsing, productivity, databasing, developing, life ...).
The heartbeat argument is an obvious case. It's the same reason people look at the UI "chrome" in the screenshots in Android Play Store - if the battery indicator is from Eclair it doesn't built confidence it'll work in Nougat!
But that may apply less to a more minimalist utility (eg a command line tool)
Merely to update it so that you formally confirm that this version was tested on newer systems may be valid in some cases (although one could merely update documentation in many cases for that).
And then there is the dependency argument. Where a tool directly contains underlying packages, it builds confidence the developer won't get stuck too far behind current(ish) versions (with the greater risk of it becoming abandonware). Where the dependencies are external (ie up to the user to have installed) you do not want to be stuck on some old version, as other tools may move on, even if this super-stable software doesn't feel the need.
In general:
If I come across a 3 year old binary, and no news article about dev activity it looks "dead and unsupported". Also on GitHub, if there is no commit for 1+ year, it looks "dead and unsupported", piling up of Github issues is also a bad sign. Using "dead" binary asks for troubles down roads, when you want to use it in a few months and it stopped working.
Edit: Android devices does not suffer from this fever, btw. How good. Really. https://danluu.com/android-updates/
A long, long time ago DJGPP 2.0 was released, and almost immediately people were asking when version 3.0 was coming out.
It was a DOS port of the GNU C compiler, so really you can't make a new version of it until the next GCC comes out. Plus, the question was, "What would the update have?"
It's not like commercial software where you need to add features every quarter so your competition doesn't leave you in the dust.
What software is non-security critical anymore?
LaTeX, MATLAB, CMake...
"git clone foo && cmake foo" can definitely be a security problem, and not just because the code itself is untrusted.
Any of the above is going to realistically create feature work as you work with new customers or users and find further areas for completing your product offering.
Word of caution — this work will never realistically end, or you will end. There is no end state to software. Software is the tool, the product is your user or customer community and the problems you solve together. If you’re looking to build software as an end state, I see obvious problems, and your customers do too.
Actually I wouldn't really want another update at this point, because I already have a code base built on the existing thing that does what I want and adapting to new/changed stuff would distract from developing features specific to my system.
Such discussions usually end in one final argument from the new developer: "But your version is no longer maintained!"
I can see the angle as a developer that there isn't anything new this week/month/quarter in the software. And I can see the user angle that if it hasn't been updated perhaps updates are no longer available.
That makes me wonder if an update that says the software continues to be in good shape (a non-update update) would assuage the user. Something like that could be automated and so not impact the developer.
That doesn't sound like the most charitable reading. A lot of customers expect updates to mean performance improvements or security fixes, neither of which they'd be able to ask for with any kind of specifics.
If it needs a fix, update it.
If you want to increase awareness, add a feature.
If people are paying a software support fee or have a contract stating a certain number of releases a year then do releases.
Otherwise why risk introducing new problems
The result can be an app that requires minimal maintenance and it might work for years without any changes at all.
I'm using the Atom editor. It's kind of annoying how it pushes new updates every week. Previously used Subline Text 2 which just worked and did not have an update for years.
"Bug fixes and stability improvements"
"Thank you for using <X>! For your benefit, we update <X> continuously. Every updates for <X> potentially includes new features, bug fixes and other improvements. Don't hesitate to reach out to noreply@<X>app.com if you have any questions or suggestions."
"Bedankt dat je <X> gebruikt! Bij het invullen van de releasenotes heeft onze stagiair niet opgelet en per ongeluk de verkeerde taal geplakt. Geen probleem. We hopen dat je van deze nieuwe versie geniet!"
(For the longest time, the Dutch Facebook Messenger app had release notes in some Scandinavian language.)
