Hi Tristan, Thanks for getting back.
I fully expected some fireworks on this thread, as versioning debates can do that very easily :) > > 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. Glad that we agree on this part. I'll add it to my to-do list to move this error to the right place. > > 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). Thanks for clarifying this. > 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. I can definitely see where you're coming from. And I can see the value in that. And, while I may not necessarily agree that this is a better versioning strategy, I can appreciate its benefits and won't push this issue any further. Thanks, Chandan
