Closed elfring closed 10 years ago
Not sure what is the issue here. Build date is just an extra information that tells a user when a software was built. It's used only in About dialog to display a build date, so it doesn't really affect application's logic. It's used as a null-terminated sequence of characters, which is guaranteed to be by the standard, so the code shouldn't fail. The only issue I can think of is that users might think that the built date is co-related with the version number, which is not true -- on day X you can build v2 and on the next day, day X+1, you can build v1.
How do you think about to get this application ever into a package for a software distribution like "Debian"?
The same way digikam got in there (I got that idea of having build date in About dialog idea from them).
You copied an implementation detail which will need further considerations. Would you like to achieve executable files that will always be generated with the same content for various software releases (independent from the build time)?
I suggest to reconsider the use of the variable "buildDate".
It looks nice occasionally to store a time stamp in generated files. But such an information can result in software development challenges to get a reproducible build result. How do you think about to make this implementation detail configurable?