Quote:
|
Originally Posted by Pierre-Marie Baty
I hear you Austin, I hear you 
However this win32-specific version stuff does not suit the version convention scheme I'd like to use. I version stamp most of my files under the form YYYYMMDD[-b] for year, month, day and (optionally) build, such as "version 20040229-2", which tells me the file was the second release built on february 29, 2004. Windows, on the other hand, wants me to version stamp my files like "1.0.0.1" or so. It doesn't represent anything for me... 
If you tell me I can keep my version convention scheme with the Windows version stamp resource, I'll add this version stamp resource right away to all of my projects, I swear ! |
PM, I woudl say this fits in almost exactly with what you described.
The only downside is you can't have leading 0's,
otherwise it is exactly what you wanted but with "."
AND you COULD use the file and product version anyway you want to since it is free text.
I agree the version resource, like SOOO MANNY things was totally duffed by
the V-O-L-E. (the inq.'s (http://www.theinquirer.net) pet name for MS. Look up vole at dictionary.com! ahaha! )
Yes, tell me why few if any ms executables follow this 1.1.1.1 ridiculous scheme, but their development tools seem to force this on us.
BUT, I believe ANY version stamping is better than NONE even 1.1.1.1.
I believe totally in the simple major.minor version scheme.
This is easy for the end users to deal with, the whole point.
The version isn't for developers. We should have build numbers internally that we use.
For a professional product you SHOULDN'T have a bunch of releases!
(Steam for example. What a mess... sorry to say…)