Version numbers is 1.13 > 1.2?

Question

I know from the .NET perspective that an assembly with a version of 1.13 is considered a newer release than version 1.2 because each number in the version is evaluated individually. However from a numerical point of view 1.13 is < than 1.2.

The issue comes down to readability when publishing updates for customers. From .0 to .9 it's all the same but at .10 you have to differenciate. So, do you limit the number of point releases to 9 and then increment the major version when you reach .9?

Please don't assume that the end user has an understanding of typical development version numbering schemes.

Update:

Don't think of it like a decimal number. The (.) is a delimiter between the different fields. What each field means (for example):

 MajorRelease.MinorRelease.BuildNumber

Absolutely! That'show I see it when I look at version numbers. But it's not how your average Joe reads the text '1.13'. I guess as programmers it's easy to project our understanding on our users. That's why I'm interested in responses on experience with confusion on the numbers. It may not be a real issue, or perhaps it's just been ignored.

Update 2: Response to "provide documentation" or "explain it to users" type solutions: they don't work! :) If you have to explain a version number to the user you've already made it more complex than it needs to be. While the primary audience for a piece of technology may be developers in many companies the actual procurement and management of software is handled by secretaries and clerical staff who have no development or technology background at all. If their manager asks them "Is there a new version available from 1.9" and they see "1.11" they may not register it as a newer release.

Answer 1

Version numbering can be confusing if the version numbering looks like a numeric decimal, but the (.) is actually a delimiter between independent fields which should be read something like this:

MajorRelease.MinorRelease.BuildNumber

Each number is independent of the rest, so version 1.12.99 might be be followed by version 1.12.100 (for example). So you end up with:

In release 1, Minor Release 12... build 100 comes after build 99.

So in your example (v1.13 > v1.2): minor release "13" would have come some time after release "2".

Answer 2

This is standard practice, and anyone paying attention to version "numbers" really ought to be aware of this anyway. The only reason there might be any misconception is if your version "number" only has a single dot, e.g. "1.13", in which case it might potentially be confused with a decimal number (by an unaware reader), which is unfortunate because they represent quite different things although using the same notation. Do you use revision numbers? If so, this makes it a lot more clear that the versions aren't decimals, e.g. "1.13.2". I would tend to recommend this practice anyway from a design point of view.

Side point: If you want to compare versions of assemblies programmatically, you can just use the Version class, which overloads the comparison operators so you can check easily which is more recent just by evaluating versionA > versionB.

Answer 3

1.13 > 1.2

If you think that it might confuse customer, dodge the problem - start numbering from 1.10 :)

Answer 4

I prefer to always zero pad version numbers to avoid confusion and allow them to sort properly in "version unaware" applications. In this case I would number 1.13 > 1.02

The advantage is that it sorts properly both numerically and alphabetically.