5 Answers
5

The first number in a machine oriented environment might be "0" but i suppose that it would actually be confusing for the people involved in the project – so you better stick to the "1" as the first (1st) number. Otherwise you will sooner or later have continues problems when talking on the phone about "the third version" which would then have the "2".

And additionally I can just recommend to keep it simple – instead of having "0.0.0.1" I would instead start with "0.1". Then continue through "0.2 … 0.9" and then go on with "0.10" and "0.11" and so on.

Once you have a stable version or a first release call it "1.0" –– the first update of that version is then again "1.1" and so on. If it's untested you could add a "b" for "beta" and if it still is very buggy add an "a" for "alpha".

btw: at some point it might be that the client (or "the other people") expects the final version already after "v0.9" – and some others might think that "v0.9" is something like a dead end and want to continue with "v0.9.1" or even worse "v.0.91" –– but it should be "0.10".

I'm limited to the four digit version number (x.x.x.x) by the software I am using. But then I guess the users don't need to know that.
–
UrbycozJan 25 '13 at 10:17

@Urbycoz: 2 of those 4 digits are for more technical people. That is, you announce the first 2 digits but used the last 2 to differentiate between different versions of the same product release (e.g., one of those extra digits could be a build number that increments on every compile). Only the first 2 digits are normally used within advertisements and promotional material, but you may use the last two digits for technical support (e.g., determining if your users are up to date on patches).
–
BrianJan 29 '13 at 18:53

Usually versions starting with 0 pre-production or beta/alpha versions. Once they are in a public (non beta) level of development, they usually start numbering from 1.

So the very first development version would usually be something like v0.0.0 (with as many dots as you like), but v0.97.2 would still be pre production ready. V1.23.2 would be an early production version, and v17.87.3 would be much later.

There are however many exceptions to this, and no hard and fast version numbering rules.

As you surely understand - this is a mine field you're stepping into with this question. But it's great fun and I'll do a reasonable try to answer this question. So lets start in the beginning, shall we?!

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is actually computer software. Reference: Software Versioning

That said there is no convention of how many groups of number to use. Some use four groups (like Microsoft), others three. The important thing to remember is that the order is left to right. 1.0.0 is greater than 0.9.9.

There are some developers who use 0 for alpha version, 1 for beta version, 2 for release candidate and 3 for final and production ready.

Some rare cases like SmartEiffel use negative numbers starting at -1.0. The S.u.S.E Linux distribution started at version 4.2 referenceing 42, "the answer to life, the universe and everything" mentioned in Douglas Adams' The Hitchhiker's Guide To The Galaxy. The current Slackware version is at 13.37 referencing leet.

So it's fair to say that anything you use is neither right nor wrong. The advice would be to use a versioning system that works for you, and that you document how your versioning system should be read.

While the convention seems to be that main version numbers can start with 0. I don't think there ever is a 0.0 or 0.0.0 version.

The leading 0 suggests development, i.e. "not yet a released version" - as compared to 1.xx and so forth, which show the main release number.

You should definately start with 0.0.0.1 - any version you publish is already a version, so logically, there can't be an absolute zeroth version of your software. The initial zero just designates the overall development status, but each release has a positive integer number somewhere in the subversion numbering.

Reading through this wikipedia article will be helpful. Even though there is no definitive answer it certainly does not show any examples of 0.0.0 as initial version, but mentions 0.xx as designated beta or pre-release.

Edit:

semver seems to be a popular guideline for versioning, and in its faq it states (retrieved 2013-01-29):

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.