I was interested to see a more formal definition of calendar versioning than I've come across before, until I saw that it refers to `DD` for short day while `0D` is zero padded - which goes against all date formatting specifications ever... `DD` should be zero-padded and a single `D` unpadded...
Are they trying to make this as obscure as possible? After reading the top of the scrollable page, I still couldn't understand what a CalVer version string looks like.<p>Also, I think version strings should contain information about compatibility, not just about time.
I decided to use calendar versioning for our companies internal ERP system since it makes it explicit to end users when a new release has been rolled out (2018-06-06.1 is more human than #9b867341 or 27.1.321.1).<p>No reason other than that.<p>I also change the background image of the login page on 'major' releases where significant new features are added as a subtle visual cue that users should go check out the change log.<p>It's often the little touches that have a disproportionate impact on user engagement.
I'm surprised to see some of the most popular software of all time not be mentioned: Windows and Microsoft Office.<p>Also, for a more technical audience, the C, C++, and EcmaScript specifications.
At GitLab we just bump the minor version every month. And when there is a breaking change we bump the major version. The advantage is that semver is well understood and we can communicate breaking changes. The disadvantage is that you need to look up what version was released when.
> <i>0Y - Zero-padded year - 06, 16, 106</i><p>It seems very odd, to me, to make this a variable-length field. If you're planning out to 2106, why would you not use a full length year? This particular bike shed should clearly be blue.
CalVer is also nice for mature projects that don't get new groundbreaking features because they don't need them.<p>I wrote a small piece of code in my project's setup.py [1] that computes the version number from the timestamp of the last git commit. It's very useful because it removes the need to make a commit for the sole purpose of updating the version number. (I also had issues at the time there were multiple forks of this software, merging each other, causing conflicts on the version number.)<p>[1]: <a href="https://github.com/ProgVal/Limnoria/blob/testing/setup.py#L54-L64" rel="nofollow">https://github.com/ProgVal/Limnoria/blob/testing/setup.py#L5...</a>
Where i work, most of our libraries have a version number with a single component, which we increment with each release. So i recently released a new version of AdminTools, taking it from 37 to 38. Should i go and register SerVer.org so i can tell the world about this incredibly trivial scheme?
For a mature program (not a library) I like using a combination year.counter. No semantic meaning at all apart from monotonous improvement, and you can tell how old a version is.<p>2017.75, 2018.76, 2018.77, 2019.78 etc
Has anyone successfully transitioned from SemVer to CalVer? Especially with a large customer base who is familiar with the the major product versions but gets confused with the minor/patch variants and what’s included ?<p>I’m interested in your war stories, pm me.
A version number which includes the date it is released is more common for development or “snapshot” releases, so you should only use this versioning scheme if you are fine with people assuming it is in fact that kind of interim or unofficial release.