Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > As the author of a tool, Russ has the option to change the default > behaviour to leave the date out rather than using SOURCE_DATE_EPOCH. > Russ of course has to assess what the likely feelings of downstreams, > about that, are.
I personally as a consumer of man pages find the date valuable to the extent that it matches the last release date of the package. It gives me a very quick feel for the age of a program and therefore for the likelihood that it is being actively maintained. This is lossy and often wrong, but it's right often enough that I do think it provides me with some useful information that the version number doesn't. That's part of why I'm reluctant to drop the date entirely, in addition to my worry that someone may be relying on it for something I didn't anticipate. > (In a modern dev workflow, it might be possible to automatically obtain > a file-specific date out of the git history. I don't think that would be > valuable enough to go to the effort, and it's not very much help for us > in Debian given our current source code management practices. We > certainly shouldn't be patching packages to do that.) The Python setuptools-scm package takes an interesting approach to this for version numbers that I rather like and that works for both Git checkouts and distribution wheels, and one could imagine doing the same thing for dates as well, but the hard part is incorporating this into the upstream workflow. It's not really something Debian can do directly. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
