Reproducible build and prelease information

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> During the packaging of INN for Debian, it was noticed that
> Makefile.global.in in the tarball and the one in the Git tag differ
> with:

> [in the Git tag]
> VERSION_EXTRA	= prerelease

> [in the tarball]
> VERSION_EXTRA	=

> It was already the case in previous releases.

> For the next releases, I then suggest to adapt the release process to
> manually remove "prerelease" in the same commit as the one that modifies 
> the FAQ to reflect the new version.  (This is usually the latest commit
> before the release.)  And re-adding "prerelease" in the subsequent 
> commit that also modifies Makefile.global.in to bump the version number.

Ugh, sorry.  Yeah, that's probably the right fix.  It's a bit tedious, but
I can't think of a better way to do it.

> Also, when building a prerelease version of INN, support/mkversion adds
> the current date (YYYYMMDD) in the source code, so that it is displayed
> for instance in the NNTP greeting banner.

> In order to make the build reproducible, I suggest an improvement for
> people building from Git (the date used will be the one of the latest
> commit instead of the current date).  Otherwise, it won't change from
> the current behaviour.

> if [ x"$extra" = x"prerelease" ]; then
>     # Ensure a reproducible build when the source code has not changed.
>     LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
>     2>/dev/null | tr -d '-')

I don't think you need the tr.

>     if [ -n "$LAST_COMMIT_DATE" ]; then
>         date="$LAST_COMMIT_DATE"
>     else
>         date=$(date +%Y%m%d)
>     fi
>     extra="$date $extra"
> fi

The one drawback to this is that it doesn't notice if there are
uncommitted changes to the local tree.  In this case, I don't think it's
worth handling that, but I note it just because some tools like
setuptools_scm that do something equivalent do use a different version in
that case.

I'd go with this approach, though.  The other option would be to use git
describe, which is more accurate than our historic practice of using the
date (which I think may go all the way back to CVS), but I don't feel that
inspired to switch.  (And git describe doesn't work on the main branch.)

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.