On Thu, Jul 24, 2014 at 10:34 AM, Benedikt Morbach <[email protected]> wrote:
> > > > > It depends. My own most-read javadoc is > > > http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletableFuture.html > > and that has no release version associated with it. The value of the > > timestamps may be small, but it is definitely non-zero. > > > > It depends on the use case. For Linux operating system deployments, it > makes > > a lot of sense to drop the timestamp, especially because the user will > have > > a good chance of being able to observe the timestamps of the underlying > > files. > I'm mainly arguing that for most use cases, omitting the timestamp > wouldn't hurt/would be better. > Doing this upstream in javadoc seemed to be the most future-proof way, as > it just flips the default. > And honestly, the current default is suboptimal for both use cases. > The timestamp should either be in the actual output (not in a comment) or > not present at all. > I disagree. There's a long tradition of using Show Source for humans or robots to get more metadata about the web page. Metadata that might not be worth putting visibly on the page itself. This data is not incredibly valuable, but it is occasionally useful. The same way that timestamps on files are occasionally useful. It's only a few release engineers of the world that are annoyed by the reproducibility problem (yes, I am also affected). So just go and improve your release-diffing tools. For comparison, you are not helping users if a freshly installed Red Hat system has every single timestamp set to a fixed meaningless date.
