FixedInfo().FileVersion.String() Generates Version in the Wrong Order

[teschste-reyrey]

When a Windows application is built and I look at the file's Properties, and then the Details tab, the file version values are in the order I would expect, Mahor, Minor, Build, Revision (what you call Patch). For example: 5.0.0.19

However when I use go-fileversion to retrieve the same file's version info and then use FixedInfo().FileVersion.String() to display it, it displays in the wrong order: 5.0.19.0

It appears to be putting Revision/Patch in front of Build instead of after.

[cturbelin]

It doesn't seem to be a problem in the order of the formatting but a parsing problem, the lowest and highest word are inverted for the two last version components (build/patch). They should be parsed in the same order as the major/minor ones.
It should not be fixed by inverting the formatting (this breaks the meaning of the fields following the semantic versioning convention Major.Minor.Patch[.Build])

Major: uint16(vsFixedInfo.FileVersionMS >> 16),
Minor: uint16(vsFixedInfo.FileVersionMS & 0xffff),
Patch: uint16(vsFixedInfo.FileVersionLS & 0xffff),
Build: uint16(vsFixedInfo.FileVersionLS >> 16),

Should be

Major: uint16(vsFixedInfo.FileVersionMS >> 16),
Minor: uint16(vsFixedInfo.FileVersionMS & 0xffff),
Patch: uint16(vsFixedInfo.FileVersionLS >> 16),
Build: uint16(vsFixedInfo.FileVersionLS & 0xffff),

[nixomose]

the problem isn't in the parsing, which is correct, it's just the order of parameters in the String() function.