Subday Versioning

[ixxie]

What is the recommendation for handling multiple releases in one day, when a modifier is technically not needed?

Ideas that come to mind:

• Incrementing Integer - 2024.06.26-${n} or 2024.06.26-r${n} where n increments with the releases in that day
• Timestamp - 2024.06.26-231259 or 2024.06.26-2312, i.e. an hh:mm:ss or hh:mm timestamp

[mahmoud]

Hey @ixxie! So, CalVer allows mixing of traditional version components (major, minor, micro/patch) in with CalVer components. The Ubuntu and Twisted case studies both use year and month, followed by another number. No reason you can't do YY.MM.DD.MICRO. (Unless your packaging ecosystem forbids it, I don't see any reason for a dash over a dot. The less punctuation the better imo.)

I advise against timestamp because you either run into resolution issues (two versions in the same hour, minute) or length issues. The core conceit is that you're trying to communicate to users through a number.

If you have a technical case where you need seconds in the version number, so be it, but generally humans don't go through the trouble of converting a seconds timestamp to a wall clock time and make decisions based on that information.

TLDR An incrementing integer is fine.

[ixxie]

Hey @ixxie! So, CalVer allows mixing of traditional version components (major, minor, micro/patch) in with CalVer components. The Ubuntu and Twisted case studies both use year and month, followed by another number. No reason you can't do YY.MM.DD.MICRO. (Unless your packaging ecosystem forbids it, I don't see any reason for a dash over a dot. The less punctuation the better imo.)

I advise against timestamp because you either run into resolution issues (two versions in the same hour, minute) or length issues. The core conceit is that you're trying to communicate to users through a number.

If you have a technical case where you need seconds in the version number, so be it, but generally humans don't go through the trouble of converting a seconds timestamp to a wall clock time and make decisions based on that information.

TLDR An incrementing integer is fine.

Thanks for the input @mahmoud!

I agree that timestamps have their issues.

I somewhat disagree about the separator; clearly distinguishing the part of the version which is a date, from the part which isn't, is helpful both for humans and machines.

For example, compare 2024.07.01-23 and 2024.07.01.23 - for me at least, the latter can easily be misread as the 23rd of January 2007.

In terms of parsing, I can now split by the - character and get the date of the build, whereas with only . as a separator its somewhat trickier.