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.

Answer 5

This issue has bothered me for a while too. Zero-padding for ‘reasonable’ string sorting seems like a good idea (I wish more source tarballs followed this; it can be very difficult to spot the most recent among dozens of releases otherwise).

I’ve recently noticed developers saying “1.13” as “one dot thirteen”, rather than “one point one three”, which is a practice I think I will adopt. It makes it clear that the version number is a string of numbers, not a decimal. Perhaps we should have settled on, say, dash or slash instead of dot as the separator, to make the written form less ambiguous.

If you did treat them as decimals, you would probably end up with version numbers like “1.999999” as you approach a new major version! (I remember BASIC dialects with line-numbering having a similar issue.) It also reminds me of Knuth’s numbering schemes for TeX and METAFONT (converging toward pi and e respectively, which I think is brilliant: it suggests that software with a well-defined purpose should converge towards an ideal state, rather than constantly expanding).

Answer 6

For example: 3.1, 95, 98, Me, XP, Vista, 7

Just make up something new, the client isn't worrying about it as much as you think. Explain the new features, not the version number.

Answer 7

I only increment the different versions numbers based on the importance of the release and its qualifications as a major/minor release. I guess I don't really care too much about readability of version numbers.

Answer 8

no. In every software versioning for delopers i've seen, 1.13 > 1.2

Answer 9

However from a numerical point of view 1.13 is < than 1.2.

I don't think so.

So, do you limit the number of point releases to 9 and then increment the major version when you reach .9?

no. My numbers go into the tens. Larger projects go into the hundreds, for the interim builds.

Answer 10

I don't consider the version number to be one numeric number, but rather an array of numerical elements. As such I have always found it natural that 1.13 > 1.2. I would not increment the major version just because the previous minor was 9 and somebody might think (even though I find it unlikely) that 1.9 is later than 1.10.

Answer 11

Versioning numbers is just for you to know what build you are working with and for the users to see what version they have.

How you do it exactly is up to you.

You could do A.B.C or I.II.III or what ever you fancy.

I try to make it simple for the user to understand. Since I personally don't care how it is.

I have three tiers. Major.Minor.Build

The build is optional, on projects that update often I attach the revision number on there to see where we are sitting.

The numbers on Major and Minor are whole numbers, so 13 is larger than 2 but usually we never go so high in the Minor revisions, we rather tend to batch together minor builds and push those into 1 major one.