Beta versioning best practice?

[cbarlow]

Can anyone offer some insight on the best way to version from beta to release? The issue is we use three version numbers when we release: 1.0.0. With each update, we increment the third element, 1.0.1. We just switched to a Basic MSI install project, and this all works fine. In beta mode, though, we have problems. This is because we use a fourth element. 1.0.0.0. Ideally, we would increment the fourth element in beta and when we release, we drop the fourth element and start incrementing the third. Since the fourth element is ignored in MSI patching, it means we can't test our patches until we release. We're considering this instead:

beta1: 1.0.000
beta2: 1.0.001

release1: 1.0.0
release2: 1.0.1

Does anyone know if 1.0.0 is considered a later version than 1.0.001? Any help would be greatly appreciated.

[MichaelU]

Generally not; the comparisons are supposed to be made by treating each section as a number, so the number 001 is equivalent to the number 1.

[cbarlow]

So are there no guidelines on the best way to handle version numbering between beta and releases? Does microsoft have a standard we could follow?

[MichaelU]

Not that I know of. Microsoft tends to use these as Major.Minor.Build, where Major and Minor are clearly determined ahead of time, and Build can be an arbitrary increasing number other than zero. Say with 7100 being RC1, and 7600 being RTM...

[mlerch]

We use them as Major.Minor.Patch.Build, e.g.

9.0.0.138 - major commercial release of 9.0
9.1.0.54 - minor commercial release, 9.1
9.1.1.3 - patch 1 of 9.1
9.1.2.7 - patch 2 of 9.1

now I'm preparing our beta program, and our betas differ only on the fourth number - the build number in our case, and I'm getting complaints about msi not handling file version numbers out to the fourth element.

and it's also not working; the file is not getting updated. yet. 🙂