Picture yourself: your browser tells you that there is an update. You go get the new shiny thing. And then, when you look at the date on it, it says more than 14 years ago. Confusing, neh?
I guess using the date of the latest Git commit would just work great.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
we can use the time of the commit from tor-browser-bundle.git. The drawback is that we can't do partial rebuilds anymore, as any commit will change the timestamp used everywhere
we can use the time of the last commit on the gitian descriptor file. However, the descriptor files are not always changed between two releases
we can use the time of the last commit from one of the remotes specified in the descriptor (tor-browser.git for the firefox descriptor)
we can manually set a value for REFERENCE_DATETIME in gitian/versions and update it while preparing a new release
Partial rebuilds are worth to have. But I actually don't see how any of the four possible solutions you brought up solves this bug while keeping this option. I mean, even if we set REFERENCE_DATETIME in gitian/versions the timestamps would be different (e.g. those embedded in binaries that don't get rebuilt).
If we set REFERENCE_DATETIME in gitian/versions, we can update its value when preparing a new release, but keep the same value for all the intermediate builds we do for one release. This does not allow partial rebuilds between two releases, but allows it for intermediate builds for one release.
I had some ideas here this morning. First, it occurred to me the build id things is orthogonal to the user confusion this ticket is about. I opened legacy/trac#19528 (moved) for the former.
Can't we just adapt the timestamps in the bundle step by either using something hard-coded or preferably by e.g. extracting the date from the changelog in the mkbundle* scripts and making that available in the bundle step?
Using current timestamp of commit or tag or anything has some complicated issues to work out, understandable.
What's wrong with just setting to 2020/1/1 00:00:00? No more issues with OSX saying the current version is newer, and minimal effort needed, or am I missing something?
legacy/trac#22595 (moved) is a duplicate. Note, it might confuse tools if the timestamps are set to a fixed date. Thus, we should try to find a solution that is avoiding that.