New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not include date in binaries #6581
Conversation
and do not claim copyright for 2018 in order to make nim package builds reproducible. See https://reproducible-builds.org/ for why this is good.
Having to update the year every year manually is worse than the current solution. |
Is there a way to have the |
What's the point anyway, diff the binary files with a tool slightly smarter than |
In openSUSE we already have a smart tool called However, claiming copyright for future years is something I find questionable independent of that. |
Ok, that is beginning to sound good. But if that env var is not set, it should continue to use the current time.
I don't understand this, it uses the current year. |
Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018. |
See also http://rb.zq1.de/compare.factory-20170807/nim-compare.out for how package diff looks. |
Since I work every day on Nim, this is a theoretical issue. Once development slows down I can reconsider this. |
No, you are working every day on the master version, but when I talk about today's version, I mean |
Is dating copyrights even useful today? Version information (version number or Git hash) can easily be looked up online, after all. |
In fact, the date shouldn't be updated according to this: https://stackoverflow.com/a/2391555/492186. We should be using "Copyright 2004" everywhere! |
It is not beneficial to move the year forward if only one date is present. The initial date should stay the same and ideally match the true year of authorship. It's possible to use a range e.g. "2004 - 2017", although it is not a requirement. |
and do not claim copyright for 2018
in order to make nim package builds reproducible.
See https://reproducible-builds.org/ for why this is good.
An alternative approach would be to implement using
SOURCE_DATE_EPOCH
for CompileDate and CompileTime