As far as I can tell I actually tend to use something like this also (semver annotated with some form of timestamp, if only so I can tell at a glance how old so

As far as I can tell I actually tend to use something like this also (semver annotated with some form of timestamp, if only so I can tell at a glance how old something is, but usually as two distinct fields), but even after looking at the linked site I'm confused by what "the age of the software in days and minutes" means exactly. The current version is reported as 2.1.2329.415. Does that mean this release (roughly v2.1.something) was compiled/packaged/released 2329 days and 415 minutes after some arbitrary project-start timestamp? That this was compiled/packaged/released 2329 days and 415 minutes _ago_? Are those literally the "days" and "minutes" fields they're talking about? The former seems kinda crazy (as the version number would be mutable) but to be honest that's how I'd naively interpret "the age of the software" - I want to know how long ago this build was created, not how long after the project was first started. If the version number is days-after-project start, why not just use the actual date? What's the value of the arbitrary baseline? (Actually, now that I think about it I guess the arbitrary baseline does have an advantage if you are intentionally trying to obscure how old the build is in calendar time. *.2329.415 provides an easily interpreted, monotonically increasing identifier without making it obvious if this release happened yesterday or 10 years ago. I.e., this solves the problem that products with the year-of-release in their name have - surely people are eventually stop buying FooBar2015, whether or not there's a real need for an update in the past 5 years.)