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

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 2

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

Answer 3

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 4

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 5

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 6

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

MajorRelease.MinorRelease.BuildNumber

Each number is independent. So, for example, version 1.12.127 comes after version 1.12.82 because, when you think of it as three separate fields...

In realease 1, Minor Release 12... build 127 comes after build 82.

Enjoy,

Robert C. Cartaino

Answer 7

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.

Answer 8

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 9

1.13 > 1.2

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

Answer 10

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.