Feature request: Add build date to the Help->About dialog

[anymouse404]

Sometimes, it would be nice to easily find out how old my installed build is.
It would be nice if in addition to the revision number, the Help>About dialog contained a date of either the last commit or the build.

[ruevs]

SolveSpace has always had a rather "simple" versioning approach. For example during the whole five years between v.2.3 and v.3.0 all builds from master were simply 3.0 and the commit hash. If we add the date of the last commit it is redundant - one can simply look up the commit on GitHub by going to (example for 3.0) https://github.com/solvespace/solvespace/commit/0e0b025 where the last part of the URL is (a part of) the commit hash.

If on the other hand we add the build date there could be multiple binaries built by different people at different times from the same commit showing different dates in the About dialog - this does not carry information - since anyone can build whatever they want - but adds confusion.

Because of the above I think we should not add the date.

Finally @phkahler, @ppd, @jwesthues now that 3.0 is released should we change the minor version in master to 3.1 to match the approach used so far?

[phkahler]

@ruevs I'd like to get a 3.1RC out soon, so maybe wait until then? I think leaving it 3.0 for all the edge builds since 3.0 might have been a mistake. It shouldn't be 3.0 for pre and post 3.0 official ;-)

BTW @ppd I saw your email on my phone, just need to get to it. Not feeling well this week.

[anymouse404]

That makes sense from dev's perspective, but it is very cumbersome and confusing from user's perspective. I get that the build date is not reliable, but there really should be some information about the age so that a user doesn't have to cross-reference the commit hash, if they know how to make sense of it at all. Redundancy is good in this case IMO.
I don't know about what the build system and the program allows. Would it perhaps be possible to show date of the commit the same way that it currently shows its hash?

[ppd]

Versioning is really a matter of philosophy, I guess. I'm rather fond of bumping the version just before/when tagging a new release. Dev/edge versions should then always be named according to the git describe scheme, e.g. v3.0-101-g985e4fb, which clearly shows how far we've come since the last release.

Advancing the in-source version before tagging the release leads to confusion when you then decide to do major release instead. This is probably not really a concern for solvespace though.

[ruevs]

By the way the commit hash is obtained here https://github.com/solvespace/solvespace/blob/master/cmake/GetGitCommitHash.cmake in a very clever way by looking inside the .git directory directly. I like this a lot since it will work on a system that somehow (?!) has a zipped up project but no git installed. This will not be as easy for the date. @rpavlik at the same time has a rather complicated cmake script(?) to get information out of git here https://github.com/rpavlik/cmake-modules

[rpavlik]

We do lack the "commits since last release" component of the git describe string, and we use ~ between the version and the git commit despite ~ meaning "this actually precedes the version described so far" in Debian-speak. I'd be happy to see that string change to be just a straight git describe output, probably provides a better idea of age than what we have.

I'd strongly recommend against using a date, though, since the trend in open source is toward reproducible builds (you should be able to set up a build environment in a specific way and get the exact same bits that came in the package) and thus including build date is greatly frowned upon and typically patched out by distros. (Date of last commit is probably OK but harder to get and less common that just using straight git-describe)

Most of my cmake script isn't used if you only want git describe data. It's complicated because it has to find a file that will change when the git commit changes so that it can trigger a CMake re-configure, while also coping with submodules, being in a submodule, not being called from the root of a repo, being in a git worktree without a separate git dir, etc... it's by far my most popular module and most widely used, and the source of nearly all of my StackOverflow cred ;) You can trust that it works without caring too much about the how/why, hopefully.

[ruevs]

@rpavlik very good point against adding the date

I actually found your CMake script on StackOverflow while searching how to do git describe for this issue :-)

[rpavlik]

I can probably do this (using my module) if nobody beats me to it.

[phkahler]

I agree with reproducible builds. That said, if the last commit date is reproducible that may be nice to add. Debian guidelines are probably better to follow than none.

[gitname]

Sometimes, it would be nice to easily find out how old my installed build is.

Maybe this could be accomplished by updating the "About" window so the version number is a hyperlink to the associated commit on GitHub (instead of being plain, non-interactive text).

For example:

Given the following "About" window:

The 3.0~0e0b0252 text could be a hyperlink to: https://github.com/solvespace/solvespace/commits/0e0b0252

• I think the general URL format is: https://github.com/solvespace/solvespace/commits/{git-commit-hash}

That would serve as a one-click way for the user to determine the date of the latest commit included in the build.

[ppd]

@gitname That is an excellent idea.

[ruevs]

The idea is indeed excellent - I also thought about it but we will need to figure out how to do it on all platforms. The website/help menu item already opens a link so we have some relevant code. I will look into it.

[ruevs]

Here is how we open the website from `Help | website / Manual" menu

solvespace/src/solvespace.cpp

Line 1039 in 5efc148

Platform::OpenInBrowser("http://solvespace.com/helpmenu");

And just below that is the About dialog. It is not going to be trivial to make the version a link. But we could easily add an extra menu item. But what to call it?

There is also an unused one

solvespace/src/textscreens.cpp

Line 93 in 5efc148

Platform::OpenInBrowser("http://solvespace.com/txtlink");

it got orphaned here 5853fa0