3 ms·

Pollen has my favorite version numbering system, a blend of semantic and chronologic: > “Consistent with Racket’s version-numbering system, the first digit ref

Pollen has my favorite version numbering system, a blend of semantic and chronologic: > “Consistent with Racket’s version-numbering system, the first digit reflects major updates to Pollen that break backward compatibility. The second digit reflects feature updates that don’t affect existing features. > > “Inconsistent with this system, Pollen’s version also appends a build number, which is the age of the software in days and minutes.” — https://docs.racket-lang.org/pollen/version-notes.html https://docs.racket-lang.org/pollen/version-notes.html

rodw 7y ago
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.)

rodw 7y ago

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.)