On Fri, Dec 23, 2016 at 11:52 AM, Chris Lamb <la...@debian.org> wrote:
> > To me it doesn't sound unreasonable to consider the last segment of the > > build path part of the build environment > > Could you elaborate why? We feel that the entire build path including > the basename(1) (or "last segment") to be: > > a) something up to the local package builder to decide. > > b) A poor method of storing metadata. It seems quite fragile and also > non-intuitive; if a user searches the source tree for the version > number, they won't actually find it within any of the files! > Not having the version in the source tree is actually intentional: this way, we can promote a certain commit to 'release' without having to add 'bump version to X'/'bump version to (X+1)-SNAPSHOT'-style commits to the history. This way we avoid some risks: - if you commit the released versions, people branching from that commit might accidentally build binaries that seem/claim to also be that version even though they aren't. When using tags instead, you can't really accidentally tag multiple commits with the same tag. - if you don't commit the final version (and commit 'x.y.z+1-SNAPSHOT' or something similar instead), there is no commit that is byte-per-byte identical to a git commit. I like to have that (I can even sign that commit which is nice). Our comprehensive testing framework deliberately varies this build path to > flush out these issues FYI. > Yes I figured it was probably intentional, so I thought I'd reach out and find out why :). Kind regards, Arnout
