Printing hash number in version is nearly useless about gmt HOT 8 CLOSED

Why do you think that's useless? You can find the exact commit that you built with that information with a git log | grep 58c1d0d or online through the Github search box https://github.com/GenericMappingTools/gmt/search?q=58c1d0d&type=Commits

The date is problematic because there might be several commits on the same day. Plus, we'd have to include a timezone for it to be actually meaningful.

from gmt.

That hash number is in replacement of the SVN revision number. But contrary to the revision number that was a sensible way of having an immediate age for that build (at least for us), the hash number tells us nothing unless we do (if we remember how to and have patience to run the command) like you said.

A date, though not an exact description of last commit from which the version was built, gives a very good approximation and with no effort.

from gmt.

How about having both? That way you can easily tell if your build is outdated and when users report the version of GMT that's giving them trouble we know exactly which commit they are using.

from gmt.

It becomes a bit long, but I'm OK with it.

from gmt.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

from gmt.

What's the decision made at the Faro summit? Are we going to include a date in the gmt version.

from gmt.

I remember the issue being addressed but not sure if really made a decision.

from gmt.

I think we were OK with adding the date in addition to the hash. It is not hurting anybody to see

psxy [core] 6.0.0_316d1c7_2019.03.06 [64-bit] - Plot lines, polygons, and symbols on maps

If anyone knows the magic to add such a date string please do so; maybe @seisman who figured out fixing the hash in the first place knows how already?

from gmt.