Duplication of versioning

[lfield]

The recent server versioning PR #2838 duplicates the functionality of generate_svn_version.sh. For example running db_dump --version on the server outputs:

2
2018-11-30 13:26:19.6759 db_dump starting
19a6483 [https://github.com/BOINC/boinc.git] (boincai05.cern.ch:/usr/local/boinc/software/boinc_src/boinc [(detached from server_release/1.0/1.0.1)])

The version should be stored on one place place and found by one mechanism. Thoughts?

[brevilo]

I'm not sure how generate_svn_version.sh and db_dump are related but I agree with you that this feature should be centralized and not be implemented redundantly.

In fact, this is another reason to factor it out of and thus decouple it from setup_project.py (see #2838 and my comment on it).

To be honest, generate_svn_version.sh is more much along the lines of what I would expect from such a functionality than, in contrast to #2838, as it doesn't make any flawed assumptions on the repo used.

[brevilo]

How about extending generate_svn_version.sh with the latest common server base tag detail (via git describe --abbrev=0 --match server_release/*) instead?

[lfield]

generate_svn_version.sh puts version.h in the source tree so as far as I understand the constant is built into the binary and is copied via install or upgrade. Adding a creating a release.inc file is sort of a similar approach. However the use of generate_svn_version.sh kind of invalidates the comment from @davidpanderson and release.inc should therefore be put in html/inc. But we could make generate_svn_version.sh put release.inc into the source tree and add it to git ignore as is done for svn_version.h.

[bema-aei]

First of all the 'server versioning' and generate_svn_version serve two different purposes: the server version should point to something generally understandable, like a version tag, for publication and subject to public inspection.
In contrast, generate_svn_version is mainly used to record the exact code version in the compiled binaries, thus it first and foremost gets the SHA1 from the git repo. This might be meaningless to the public when built from a private branch.
I agree, though, that having the server release (tag) recorded in the version string as well is useful. So I second Oliver in proposing to augment the version string generated in generate_svn_version with this information (if available), and maybe make get_project_config.php etc. read from that for consistency.

[brevilo]

However the use of generate_svn_version.sh kind of invalidates the comment from @davidpanderson

Why? Doesn't he just argue to have a single file generated (e.g. in project root) and let all "consumers" use that file where needed? I share that that thought as it is what I meant by "centralized".

[lfield]

I guess but the C programs already have it included.

[brevilo]

I guess but the C programs already have it included.

I can't follow. To whom is this addressed?

[lfield]

@brevilo and @bema-aei, please take a look at #2861.