Our application is quite mature, and thus we are up to version 16. However, this can give the impression that the software is old and out of touch (how many commercial applications are there with a version 20+??)
Obviously, version numbers are quite arbitrary - what do other people use? I quite like the Ubuntu approach of month.date, but I'd like to see what other strategies people use.
We tend to go with something like 1.20.5, where the 20 is, in your case, the fairly high 'release' number or something.
When we completely re-write a product in a different implementation, it becomes 2.0.0, and so on.
It also means that the beta versions can be 0.2.3, for example.
I think it's pretty standard to use a sub-version format like 1.1 or 1.1.2 or something to that effect for just bug fix releases, minor additions, etc... and then plan to increment the main version number on major releases.
My company develops product for 19 years, and we have only version - 3. Although we had 1.2, 1.5 and so on. I think this is the best practice.
We use Microsoft's system (or at least their documented system - real binaries seem to be rather less consistent):
Whenever a version part is changed, all parts below it are reset to zero rather than just changing independently.
As Christian said, we used major/minor numbers along with month-date for release.
For internal usage, we use CVS's date. In our case, product is fairly small, we refer with md5sum when talking to QA folks.
Version numbers can be used to sell upgrades to non-technical people either from the perspective of the software vendor wanting to get people off old versions or the user trying to get management approval to upgrade.
If you were to say that you are using "Version 20" this doesn't immediately mean anything to everyone.
If you say that you are using "Product X 2005" everyone understands that it's a 4 year old product.
(Technical people probably don't care either way!)