Most places use something like this:

Major Release.Minor Release.Hot Fix.Build

Your version numbers would look like 1.5.0.15, etc.

A lot of free software uses a three point system: X.Y.Z where

• X is for compatibility breaking releases.
• Y is for other releases, with even numbers being stable and odd numbers being unstable.
• Z is for fixes.

This way version 0.28.1 is a stable release with one fix and 2.9.0 is an alpha release with zero fixes.

Some people also have fun developing their own schemes. E.g. Tex which by each release approxed Pi, with version numbers: 3, 3.1, 3.14, etc.

It does not really matter, as long as you can use the version number to identify your versions (i. e. either add your source control system s internal revision number into the version number) or use it for tagging your releases.

When you do so, you might want to use that number as your third (or fourth) component. It looks confusing if some product jumps from version 1.12345 to 2.12346, but jumping from 1.4.12345 to 2.0.12345 is more common.

About which number to start, I just want to quote Eric S. Raymond:

In the closed-source world, Version 1.0 means "Don t touch this if you re prudent."; in the open-source world it reads something more like "The developers are willing to bet their reputations on this."

You can use whatever numbers you want in your versioning - who s going to constrain you?

If you want your first version to be 0.0.0.0.0.0.0.1, that s fine, albeit a little silly. If you want your first version to be 106.3, you can do that too, but that s a little more ridiculous.

Check out the Wikipedia article on Software Versioning for some tried-and-true ideas of realistic version numbering schemes.

I ve always used (rewrite).(feature added).(bug fix).

But set your own rules and make them public so your users understand them.

Take a look here. python setuptools has a very interesting and clear specification for version numbering. I m sure you can obtain some very insightful hints from it.

To the best of my knowledge, there is as yet no government agency dictating how you number versions. But don t worry, I m sure it will come soon enough.

Ditto on those suggesting major-dot-minor-revision. My general approach is: Major changes get a new major version. Like, if we ve added important new features. Small changes, like added some little convenience features or one new report, get a minor revision. Hot bug fix changes get a revision.

I would definately avoid calling your first published version "0.l" for simple marketing reasons: Numbers less than 1.0 sound like a preliminary version or a beta version. I ve known people to call their first version 2.3 or some such just to make it sound like it s been around a little while to inspire more confidence, though that strikes me as a little dishonest.

how about the software which is not distributed to public like a webmail source code? do you think that the build or bug fix number is still important in this case?

10.50.1600.1
major.minor.build.revision

MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.

MINOR changes is backward compatible. Mark introduction of new features.

REV for security/bug fixes. Backward and forward compatible.

eg. In SQL server 2008 RTM version number is 10.00.1600.22 and In SQL server 2012 version is 11.00.2100.60

First field is changed due to change in project name i.e. 10 and 11

In SQL server 2008 R2 RTM version number is 10.50.1600.1 and In SQL server 2008 version is 11.00.1600.22

Second field is changed due to introduction of new features.

Third field indicate build(developed)

Forth field indicates revision i.e. hotfixes applied...

You might want to start by taking a look at the Software versioning article on wikipedia, which gives some informations about the possibilities you have ;-)

It might give you some ideas of what you could do in your specific case...

I ve used

Major.Minor.Release.Build 1.02.4.15

and also

Year.Month.Date

2009.12.10

but anything that allows you to individually track releases would work. As long as you re consistent.

We use major.minor.revision.build where revision is the SVN revision and build is the build number which is based on the current date (in YYDDD format where YY is the year and DDD the day number, so 18001 would be Jan 1st 2018.)

Having the SVN revision is incredibly useful and has saved us on more than one occasion.

Version numbers are not a concrete specification in software development.

In other words, one team may use 1.0.0.0, others may use 1.0.0 and so on. It matters not.

Just choose something that works for you.

Typically major.minor.revision is the most simple and straight forward method to use. Visual Studio for example can assign version numbers automatically for you, as can other tools. So all you are required to update is the major/minor values. The build/revision numbers are updated automatically.

I seem to remember that in the old days (I am talking Commodore here) we used a syntax like release.version.revision which could be appended with either fix and/or build, where fix would usually be a letter stuck directly to the revision. So a full number would read something like:

2.1.44a.786

But like most have already said, it doesn t really matter, there is no true standard for this. Just use whatever is most convenient for you.

After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to describe compatibility between project version (versioning schema for developer, does not for marketing).

MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.

MINOR changes is backward compatible. Mark introduction of new features.

REV for security/bug fixes. Backward and forward compatible.

This versioning schema inspired by libtool versioning semantics and by articles:

http://www106.pair.com/rhp/parallel.html

NOTE: I also recommend provide build/date/custom/quality as additional info (build number, build date, customer name, release quality):

Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545

But this info is not versioning info!!

You can use any form of version numbering you desire.

I just recommend using something that makes sense. The Major.Minor.Revision numbering is popular, but any numbering scheme you wish is "valid".

When developing software libraries, I recommend using the version number to communicate the level of source and binary compatibility between two releases.

Since you re developing a web application, a two part version number is probably sufficient. The first part is for new functionality and the second is for fixes.