Comment 1 by jteh on 2012-09-01 01:37
We already set the product version field, which you can see in the Details tab of the file properties in Explorer. We can't set the file version because our version numbers aren't compatible with the Windows versioning scheme which is very specific about numbering; i.e. it can't just be an arbitrary string.
Changes:
Added labels: cantfix
State: closed

Comment 2 by elliott94 (in reply to comment 1) on 2012-09-01 08:01
Replying to jteh:

We can't set the file version because our version numbers aren't compatible with the Windows versioning scheme which is very specific about numbering; i.e. it can't just be an arbitrary string.

I was thinking that for stable versions, (for example the latest), we could have something like 2012.2.1.0 which seems to be an acceptable string to use. For snapshots, it'd have to be something like 5383.0.0.0.

Comment 3 by jteh on 2012-09-02 23:33
I thought none of our version numbers worked, but on testing, it looks like this is only a problem for version numbers containing letters; e.g. 2012.2beta1. Nevertheless, this is a problem we can't resolve. Having a valid file version for both a beta and a final release is unacceptable.

Also, snapshots actually have a version number like main-5388. If we didn't include the main- prefix, it wouldn't be clear that this is for the main branch. Keep in mind that main-5388 and blah-5388 could be entirely different versions.

Comment 4 by jteh on 2012-09-05 01:36
We can't get the exact version number as already explained, but we can do something like major.minor.mmdd.hhmm; e.g. 2012.3.905.133. This means that later builds will always have higher version numbers. The disadvantage is that this doesn't take branch into account and point releases (like 2012.3.1) aren't reflected very well, but it's better than nothing.
Changes:
Milestone changed from None to near-term
Removed labels: cantfix
State: reopened

Superseded by #6204.