5 ms·
The main reason I don't like timestamp based version schemes is that it makes builds inherently difficult to reproduce. I wrote some code for a specialized pie
by jniedrauer 8y ago
The main reason I don't like timestamp based version schemes is that it makes builds inherently difficult to reproduce.
I wrote some code for a specialized piece of equipment earlier this year. One of the requirements on this equipment is that all package installs contain a unique version string (ie. you can't install the same version twice). So I based build versions on git hash and timestamp. This turned out to be a problem because it made it impossible to reproduce builds without hacking the build system clock. So I switched back to semver for releases.
- lugg 8y agoWhat is the point of a reproducible build if you need to rebuild it to test its the same?
- jniedrauer 8y agoThe entire point of a reproducible build is that you can rebuild it to test that it's the same.
- lugg 8y agoNo.. the entire point of a reproducible build is so that you can rebuild the same thing given the same inputs across the world different servers. Testing that md5sum(software A) works just like md5sum(software A) is just pointless?
- knz42 8y agocalver != timestamp version calver has a number picked up when the release is produced, not when the build is run.
- progval 8y agoBuild systems can (and should) read $SOURCE_DATE_EPOCH if it's set, and fallback to the system/CVS time otherwise. $SOURCE_DATE_EPOCH was created exactly for your use case. https://reproducible-builds.org/docs/source-date-epoch/ https://reproducible-builds.org/docs/source-date-epoch/