Reproducible build and prelease information
Julien ÉLIE
julien at trigofacile.com
Fri Nov 18 22:25:26 UTC 2022
Hi Russ,
And also thanks Jesse, for your message.
>> [in the Git tag]
>> VERSION_EXTRA = prerelease
>
>> [in the tarball]
>> VERSION_EXTRA =
>
>> 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.
I also did not come to a smarter way to do that in the release process.
Well, removing and re-adding a word just takes a few seconds; I can cope
with it, especially when it's done only once or twice a year :)
>> 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.
Yes! Thanks for the remark. It was a vestige of a previous command
without the --date=format argument.
> 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
Yes, having uncommitted changes is not the use case to deal with. It
might be improved, though, if someone really cares for 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've just had a look at that tool, which indeed handles several cases
including the one of a dirty working repository.
> 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.)
Committed.
I'll have a look at the snapshots generated these next days to make sure
they have the right date.
--
Julien ÉLIE
« – Il l'aura voulu.
– Tu crois vraiment ? » (Astérix)
More information about the inn-workers
mailing list