What is the UX value of having version information, in particular within (solely) command-line programs?

In particular, I'm wondering about actual version information. I've noticed some commands, like gpg --version, will produce more than "version" information: they also report algorithms supported, etc. This is different than purely "version" information, in my eyes - it's more of "capability" information. I can definitely see the value of capability information.

But from a user perspective, especially a command-line user, is it really relevant? I imagine there isn't a lot of studies done on this, so I'm happy to just hear convincing anecdotal experience. I've heard "conventional wisdom" that command-line programs should implement --version and/or -V (or less commonly, -v, which is instead often short for --verbose), but unlike the "give me help/usage" options, version information seems to be a lot less useful to have.

Most of the time, I know what version of a program I'm using because I installed it, or it's installed on the system for me and the package information can be queried, e.g. dpkg -l package-name will tell you the package version number on dpkg/apt -based systems, which generally tracks the version of the software itself very closely. And that's if I actually care what version I have - for me that only comes up very, very rarely.

It doesn't really do much harm, I guess, but if the UX impact is negligible, why bother?

  • I guess you could describe this as an edge case, it may not be used very frequently, but there is value to it in certain scenarios. I would say it's a product requirement question 'why is it here?' as opposed to 'why was it implemented like this?'.
    – Midas
    Commented Mar 22, 2016 at 12:56

1 Answer 1


This becomes particularly important if the program/tool has been in use over a long time, or — as especially happens with software development — you have multiple instances of the same tool installed. Automatic updates is another such instance you may want to find out what version you are running. And when it comes to bug reporting for the tool you simply cannot do without it.

One very simple example:

  • I develop Java programs. Java needs to be on the command line path. But the Java installer alters the path and as such I can end up in a state where it is uncertain which version of Java is actually on the path. And when I have several Java Virtual Machines installed (happens more often than you think), I may need to find out which one is actually being executed. At this point it is essential that I can just write "java -version" at the command prompt to see which one I am getting.

This is — of course — very contextual on the tool in question, and so you would need to try to think how people might use it and see if this is relevant to you. It goes without saying though that you cannot expect the unexpected, only try to mitigate its effects.

Source: http://xkcd.com/1172

In conclusion I would say: implement it, if nothing else in order that you will avoid annoying all users that do try to check for the version number and that would end up geting an "unknown command line switch" error in their face instead of what they expected. :)

  • 1
    Ah, I didn't think of the "multiples in the PATH" aspect of it. I'll admit as soon as I saw that in your post I remembered running python --version and a few similar commands in the past. I immediately noted that sometimes ls -l $(command -v python) is sufficient, but at least on Debian's java installs, that gets you an equally useless /etc/alternatives/java path, so it turns into readlink -f $(command -v java) at best. Add to that that pathnames don't really have a guarantee of telling you version information, and you have me convinced of the practical value in the general case.
    – mtraceur
    Commented Mar 22, 2016 at 18:34
  • 1
    (cont) ..even with installs through a package manager, forcing a user to do e.g. dpkg -l $(readlink -f $(command -v java)) or whatever is certainly just offensive from a user-friendliness perspective. That really leaves just more trivial tools and very specific-purpose stuff. For those, I guess the value of not frustrating expectations and supporting the use-cases where it matters is high enough that I should default to having a version option unless there's a good argument in that special case against it, which reverses my default policy up until now. Thanks!
    – mtraceur
    Commented Mar 22, 2016 at 18:44
  • 1
    Oops, I just noticed that my last example of the un-user-friendly command-line wasn't even complete, but it's too late to edit the comment now. It's not even worth one-liner-ing it: The filepath needs to be searched with dpkg -S, then the first field of that output needs to be parsed out to be given to dpkg -l. And that's with me just casually forgetting the right way to do it with a tool I'm pretty familiar with. I'm even more convinced now that I've re-read and realized my error.
    – mtraceur
    Commented Mar 22, 2016 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.