

Version Numbers Don't Matter (to users) - latitude
http://bvckup.tumblr.com/post/10218389389/version-numbers-dont-matter

======
Rusky
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.

~~~
latitude
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
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.

------
latitude
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>

~~~
stevelosh
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/>

~~~
latitude
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 :)

------
gburt
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.

------
mkopinsky
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
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
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
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
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.

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

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

~~~
jsherer
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".

------
fragsworth
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
I would also say major version numbers are an important means for additional
revenue through upgrade fees.

------
mvkel
Tell that to Minecraft fans.

