Feature request: Seconds-level versioning granularity?

[broofa]

I would like to see this spec address use-cases where versioning granularity on the order of 1-second might be needed.

For example, the use case I have is on my npmgraph.js.org site. I allow users to upload package.json files that may or may not have a version. If the case version is missing, I need to assign one. Thus, a date-based version is the obvious choice. However users may upload multiple files within minutes or even seconds of one another. So I'd like version strings that have a reasonable chance of being unique at that level of granularity.

FWIW, the solution I've come up with - that I don't see addressed anywhere in the spec - is to use the semver "rerelease" field to hold the # of seconds in the day. Specifically, I intend to use version strings of the form [full year].[month].[day of month]-[seconds in day] [full year].[day of year].[seconds in day]

[Edit: 'Just realized that the prerelease field of semver is not actually appropriate for holding seconds. My understanding of semver is that the prerelease field should indicate the anticipated version. I.e. it should follow the same form as the the normal (pre-hyphen) fields, but provide the expected version upon release. Given the nature of date-based versioning, that ends up being problematic.... 'basically requires being able to see into the future.]

[mahmoud]

Hey @broofa! This comes up from time to time in discussion, especially where automated releases are concerned, so it's definitely worth consideration. Usually the conversation lands on:

"if a release can happen in the same minute, nothing stops it from happening in the same second"

In which case, you'll want/benefit from having a release procedure that checks the existing version or uses some other locked global counter. It'll make for a smaller/more readable version, too. If readability isn't a concern, I've seen some use a git commit hash to avoid collisions.

[mahmoud]

Ah, also meant to say, for readability/intuition, fields like YEAR, MONTH, DAY are in a tier above WEEK_OF_YEAR, DAY_OF_YEAR, MINUTE_OF_DAY, and SECOND_OF_DAY.

Most people don't have a great intuition when reading (or even writing) those kind of numbers, so even though I've seen them (and used them*) on occasion, they're not recommended on calver.org.

---

• When I've used them, it was because I wanted to fit more temporal data into a specific version scheme (3-part limit). In a less-constrained situation, I'd recommend adding more segments instead of compressing the temporal info into a single field, i.e., YYYY.0M.0D.PATCH instead of YYYY.WEEK_OF_YEAR.PATCH.