Even though zip's -X flag suggests that it removes timestamps, that's not
quite true. There's still modification times per file, and that introduces
non-determinism that are hard to notice, since the mtimes are unlikely to
change without changes to the files. Only when doing a new clone/unpacking
a tar ball under some circumstances or similar action that resets/discards
the mtimes, we would notice.
So, the -X is not enough, and from what I can tell, there's no way of
telling zip to not include timestamps (or truncate them). With this
change, we stage all files in a temporary .build directory, and set the
mtime manually to the beginning of time (as is the case for zip files:
1980-01-01T00:00). These timestamps should not be important to anyone,
since they are all presented to the user as a blob.
The rationale for this change is that this makes it possible to build
svtplay-dl reproducibly. And it also removes the pesky svtplay-dl diffs
just from regenerating the executable.
pod2man will insert a date in the footer of the manpage. By default,
it takes this value from the mtime of the input file. But this makes
it non-deterministic in that another build may produce other results.
By setting it to always be the date of the latest release we make it
deterministic.
To build a new release, including tagging and commiting the release changes
(regenerate svtplay-dl, and update Makefile with LATEST_RELEASE), just do make
release. Obviously, the intended user of this target is the upstream author(s).
As part of the make release target, svtplay-dl will be unit tested and the
manpage will be checked to make sure all options are documented. All of this
happens in a local clone of your local repo. This is to make sure that no files
are left uncommited.
Finally, the changes necessary will be applied to your repo and a tag will be
set. All you have to do at this point is to verify that everything looks ok, and
then push master and the new tag to github.
