5 ms·

Version Numbers Don't Matter (to users)

16 points by latitude 15y ago

mkopinsky 15y ago
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.
- latitude 15y ago
  Yep, sure thing. This is more in a context of end-user products that tends to have linear release stream and shorter release cycles.
  - yuliyp 15y ago
    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?").
    - latitude 15y ago
      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.
      - yuliyp 15y ago
        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.
latitude 15y ago
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 http://en.wikipedia.org/wiki/Iproute2
- stevelosh 15y ago
  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/ http://semver.org/
  - latitude 15y ago
    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 :)
- sp332 15y ago
  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!
Rusky 15y ago
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.
- yuliyp 15y ago
  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.
- latitude 15y ago
  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.
  - MatthewPhillips 15y ago
    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.
stevelosh 15y ago
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.
- latitude 15y ago
  > 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.
  - stevelosh 15y ago
    http://semver.org/ http://semver.org/ provides a very useful scheme.
mkopinsky 15y ago
This makes me appreciate the fact that I work exclusively on webapps, where this pain doesn't exist.
- jsherer 15y ago
  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".
gburt 15y ago
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.
fragsworth 15y ago
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.
- jsherer 15y ago
  I would also say major version numbers are an important means for additional revenue through upgrade fees.
mvkel 15y ago
Tell that to Minecraft fans.

16 points by latitude 15y ago

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.

latitude 15y ago
Yep, sure thing. This is more in a context of end-user products that tends to have linear release stream and shorter release cycles.
- yuliyp 15y ago
  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?").
  - latitude 15y ago
    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.
    - yuliyp 15y ago
      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.

latitude 15y ago

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 http://en.wikipedia.org/wiki/Iproute2

stevelosh 15y ago
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/ http://semver.org/
- latitude 15y ago
  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 :)
sp332 15y ago
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!

Rusky 15y ago

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.

yuliyp 15y ago
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.
latitude 15y ago
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.
- MatthewPhillips 15y ago
  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.

stevelosh 15y ago

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.

latitude 15y ago
> 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.
- stevelosh 15y ago
  http://semver.org/ http://semver.org/ provides a very useful scheme.

mkopinsky 15y ago

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

jsherer 15y ago
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".

gburt 15y ago

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.

fragsworth 15y ago

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.

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

mvkel 15y ago

Tell that to Minecraft fans.