Hi Chandan,
As someone who originally thought it was a good idea to do like other
traditional softwares and manually bump the version in the source code,
but stood gravely corrected (by Paul), I have to give this a strong -1.
On Tue, 2020-08-11 at 22:32 +0100, Chandan Singh wrote:
> Hi all,
>
> (I have now ran into this issue often enough that I thought I should bring it
> up on the list.)
>
> I have recently created this issue [0] to describe this problem. I'd suggest
> having a read through that issue to get some background on this issue. The
> gist
> of it is that BuildStream complains at runtime (not build time) that it
> doesn't
> have any tags.
Sounds like this is a problem worth correcting at build time indeed.
> Versioneer (also, its predecessor setuptools_scm) is really good at solving
> that problem that it does, i.e. managing versions based on scm tags. I am not
> disputing that. I am saying that this is not a problem we need to have.
Except that "managing versions based on scm tags" is not the key,
important problem which versioneer solves (although it is helpful in
this automation, this automation is *not* the main reason we are using
it).
BuildStream takes build provenance tracing very seriously, as is
demonstrated by the verbose summarizing of cache keys in the master
build log (which is the key trace of provenance when speaking of any
binary artifact it produces, in addition to the individual build logs
of each binary artifact being produced).
Since there is a significantly non-zero possibility that a copy of
BuildStream that is not *exactly* a release version is used in
production, and for this reason it is of extremely high importance that
the copy of BuildStream I currently have on my machine says:
BuildStream 1.93.4+145.g4a8746161
And not:
BuildStream 1.93.4
This is highly valuable information about what precise version of
BuildStream produced an artifact, information which cannot be captured
better in a later build, since the build has already occurred and has
potentially been deployed.
When you are in a bind, and that latest deployment may be the cause of
your fleet being positioned two parsecs off course and in klingon
territory, you want to be damn sure that the version of BuildStream you
used to compile the recently deployed "Death Star 2.x" firmware is very
exactly the version that you think you used, and knowing for sure which
exact version of BuildStream you used might prevent the next
intergalactic conflict.
The "${major}.${minor}.${micro}" version number is just not specific
enough to pinpoint what BuildStream is responsible for a build, and I
would be in support of any course of action which does not cause us to
lose important context from the reported BuildStream version.
Cheers,
-Tristan
