Re: Re: commit 9d0f14

[Tatsuro M. <tma...@ya...>]

--- mojca.miklavec.lists
> On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> >
> > another try at timestamp.h, this time using build date
> >
> > The Makefile rule for timestamp.h was broken when we switched from
> > cvs to git, since it relied on ChangeLog always being current.
> > Proposed replacement rules have so far failed to work for out-of-tree
> > builds or builds from a snapshot rather than a full git clone.
> > This attempt simply uses the current build date, which admittedly may
> > not be newer than the last-modified date but at least has the virtue
> > of not depending on git.
> 
> I just wanted to warn you that you will almost definitely get a
> request from Debian (as soon as you release the version that will
> behave this way and they try to package it) to stop doing that in the
> name of reproducible builds.
> 
>     https://reproducible-builds.org
> 
> My suggestion would be to:
> (a) Check if you are building from git and if so, run "git describe"
> to determine the version. That's probably by far the best way to
> determine the version.
> (b) When not building from git, you would usually build from a
> released tarball which should necessarily have the version written
> somewhere anyway and then you know which version that is exactly.
> 
> Of course there are exceptions, like if someone deletes .git or
> fetches the zip from the download link from SF or GitHub or wherever,
> but you cannot solve all problems and the build date is totally
> useless in itself. I can probably build gnuplot 1.0 today and that
> won't tell you anything about the exact version I have in case I
> submit a bug report.
> 
> Mojca

I agree with Mojca’s statement.

Octave uses mecurial.
Hg-ID is represented in build process and it is presereved  in a file.

Tatsuro