Version Numbers Don't Matter (to users) | Hacker News Reader

Version Numbers Don't Matter (to users)

bvckup.tumblr.com

16 pointslatitude24 comments

Asking the user if they want to upgrade only makes sense if it can potentially mess something up, like dropping support for something or changing file formats, or take long enough to interrupt their train of thought, like old Firefox updates.

Otherwise, asking the user is unnecessary and gets in the way. In browsers, for example, any changes to the rendering engine will have to be backwards compatible and any changes to the interface will be minimal as there's not that much too change. Chrome's model does really well here.

The version number itself can be anything you want, as long as it's relatively simple- it's really only necessary when the user is troubleshooting, so it just needs to be easy to say over the phone or compare to something on the web.

Changes by definition can mess things up. From a user's standpoint, if there's no issues that they're seeing, moving to a new version offers unknown gain for unknown loss. The unknown loss can be estimated by the user's previous experiences with the developer, while the gain can be estimated based on the change log.

Just a couple weeks ago hundreds of thousands of SmoothGestures users learned the perils of auto-updating when an update introduced phone-home mechanisms into an extension which ostensibly does mouse gestures.

Perhaps I am an odd one out, but as a user I really do not like software that updates itself, leave alone silently like Chrome does. As a developer - sure, I would love for everyone to be on automatic updates, but looking at stats it appears to be not the case.

I have an app out that checks for updates and prompts the user if there's a new one. That's the default setting and it can be changed to disable all checks or switch to an automatic updates. Looking at the server logs I can tell that users do disable the update checks after the first notification, a lot of them do, like close to 25-30%. And virtually no-one switches to the automatic updates. YMMV obviously by an app and the OS, but it's still a data point to consider.

Your users don't want to be bothered by notifications. Automatic updates sound scary; they don't trust that your changes will always benefit them. It's easier to just turn the notifications off.

"Automatic Updates" makes me think of the Windows updater. Most have painfully experienced this at least once in their life.

How do you feel about web apps? They update themselves automatically and generally frequently. I think that's what Chrome is aiming for and in my experience it works well. For something like a browser where both security and features for developers depend on everyone updating, leaving the majority of users on an old version is just a bad idea.

So what do you guys think?

I am really curious to try just the date as a version number, but it seems just too alien and unconventional. The only real-life example I am aware of is Kuznetsov's iproute2 tool for Linux (or just ip). It uses the DDMMYYYY format and that's not much of an improvement over regular versions in my opinion.

Can anyone think of any other notable examples of unconventional versioning? It'd be nice to have a list for a reference.

[1] http://en.wikipedia.org/wiki/Iproute2

Try Semantic Versioning [1]. It gives you a sane, well-defined way to version projects and makes the version numbers useful and meaningful. It makes it easy for technical users and developers to get a feel for what has changed since the last time they updated.

You don't have to display version numbers to non-technical users. The update summary in this post looks fantastic for showing what changes have been made to end users.

[1]: http://semver.org/

SemVer appears to be a formalization of a common versioning scheme as applied to APIs. And it inherits some of its problems. For example,

> A bug fix is defined as an internal change that fixes incorrect behavior.

One man's incorrect behavior is another man's proper working order. Excluding crashes, missing data and other obvious bloopers, the "bug fix" needs to be defined way more formally than this. That would lead to more strict documentation requirements, which is a major bore and inconvenience to any self-respecting developer, which in turn will lead to lapses in SemVer compliance and then back to the starting point :)

It's not that uncommon. For starters there's Office 2003, 2007, 2010, etc. and Ubuntu version numbers are year.month (e.g. 10.04, 10.10, 11.04).

For uncommon stuff: Ubuntu and Android use alphabetical code names, but I guess they're not really version numbers.

Knuth versions some of his books by digits of pi or e. (3, 3.1, 3.14, 3.141 etc).

Emacs has an implied "1." before each version number. It was decided that since there would never be a "2.x" version, they would just drop the "1." (22.3, 23.1, 23.2 etc).

Edit: oh, and git names revisions by SHA hashes, so each version is effectively random!

I don't want my users to update unless they want a new feature from my software. The deal is, if they're not experiencing any issues, don't have any new needs, they might as well not change what isn't broken. I realize updates without any automated notification, the user has to seek out a new update.

That said, I am distributing business-oriented software, that is often "mission critical", or at least directly tied to the profit stream.

To mention the obvious, this won't work in all circumstances. For some technologies, you will want to branch and release (e.g.) new features in the 2.0 branch, and bugfixes in the 2.6 branch. If I'm on 2.6, I can plan to permanently stay up to date with the most recent 2.6.x release, without worrying about new features messing me up.

Yep, sure thing. This is more in a context of end-user products that tends to have linear release stream and shorter release cycles.

But even if you have a linear release stream, you've probably got branching going on internally once your product gets to have a significant installed base (i.e. you fork a release branch to let your main-line development continue while you polish the release up before shipping it). At this point, you have builds going on in two branches, and thus tracking the version numbers when you get issues reported becomes critical ("are you using release 37 installed 2 days ago or today?").

Well, the point being is that users shouldn't really be exposed to the details of internal branching. It is perfectly fine to use hierarchical versions internally, but they should be mapped to something simpler for the public releases. A one-to-one mapping, there should be no such thing as two different #37 releases.

Ah, I guess you then run into some blurring when you get to external beta testers and partners, or if you're developing an open-source product. But if you've got a closed-source product that you can manage the external releases to a single stream, then yeah, you can go with simpler public revision numbers.

Versioning software and displaying "what's changed" to end users are completely orthogonal. By all means, provide this simple summary when you pop up an update window. Also provide sane, informative version numbers for developers, especially if your software can interact with other software.

> informative version numbers

That's the thing. It is really hard to make a string of dotted numbers informative. They can obviously be used to express hierarchy of the versions, and that's useful in development context, but I would strongly argue against trying to pack any additional sense into them.

http://semver.org/ provides a very useful scheme.

This makes me appreciate the fact that I work exclusively on webapps, where this pain doesn't exist.

I would agree that the pain of displaying a version number to the user doesn't necessarily exist. Though, it is a good practice to have releases for your webapps, even if you have multiple releases per day. In this instance a revision number would accurately describe the "version".

Users do care about major version numbers, provided that the next version is substantially better or different. Take video games, for instance. We normally call them "sequels" but it is really just a significantly enhanced version of a previous product.

I would also say major version numbers are an important means for additional revenue through upgrade fees.

Tell that to Minecraft fans.

Reply on news.ycombinator.com