Normalize Heptapod revision information and its display
We shouldn't display a revision hash in the help and admin pages when running a released version
- upstream GitLab doesn't do it
- it's a bit confusing, letting the user wonder whether this could actually be an intermediate revision, since intermediate revisions done after a release typically would display it together with the latest or next actual version. Absence of revision detail is a clearer promise that this is the displayed version.
With the progress made on packaging, the HEPTAPOD_REVISION
file has lost its usefulness and is now a source of confusion
- for development instances and source installations managed with Mercurial, the exact revision information is directly obtained by a
hg log
call and that file usually not present (would be ignored anyway if it were). - for all installations from a tarball, that file is redundant with the
.hg_archival.txt
metadata file. This has been the case for Docker images since Heptapod 0.13 (see heptapod-docker!12 (merged)) and for all Omnibus driven packaging (currently only the Docker image). - it's a further complication for subsequent development of Omnibus packaging