At Cockroach Labs we switched to Calver covered in this thread https://news.ycombinator.com/item?id=19658969
CalVer: Calendar Versioning
41–50 of 102 posts
Re: CalVer: Calendar Versioning
#42I could see this being useful in some cases for marketing disambiguation. The Wifi Alliance should be taking notes. Otherwise, I don't see any reason to use CalVer over SemVer.
I would rather the version numbers be used to inform users about the nature of the changes (patches, new features, backwards-incompatible interface changes) rather than simply when the change was published. I very rarely care about the publishing date.
Re: CalVer: Calendar Versioning
#43I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
I also wish all of my data was version controlled, which is why when I created EteSync[1] I made sure to include a full change history. Check it out, I think it's exactly what you're looking for, and it's fully open source, so you can host in on-site if your company requires that.
Re: CalVer: Calendar Versioning
#44Interesting to see that so many of the exemplary projects are python based. I wonder if there's any correlation there.
Re: CalVer: Calendar Versioning
#45I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning.
Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31. These versions tell you nothing about the projects except their release dates.
On the other hand, semantic versioning (when not abused) – say LibA v3.0.1 vs LibB 1.0.0 – reveals something useful, such as, that LibA has undergone three major revisions, so perhaps it is much more mature than LibB.
Perhaps the calendar versioning works well with already mature and famous projects – e.g. Ubuntu 18.04, etc – but for smaller projects I don't think it's such a good idea.
Comment v1.0.4-20jan06
Re: CalVer: Calendar Versioning
#46I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…
It's not a good fit for libraries but it's great for applications.
edit: I'm also a huge fan because unlike semver it can be easily generated in a CD pipeline.
Re: CalVer: Calendar Versioning
#47I'm using similar versioning for pre-build packages, but it's extended with commit information to 1:1 mapping to the source tree: local date=$(git log -1 --format="%cd" --date=short | sed s/-//g) local count=$(git rev-list --count HEAD) local commit=$(git rev-parse --short HEAD) echo "$date.${count}_$commit" Example result: 20191121.68_84f90ff It provides user about general information about when program was updated…
In build2 we do something similar for snapshot versioning between releases by incorporating the date and commit id into the pre-release component of semver. The result is a unique, properly ordered version for every commit in a project (we call it "continuous versioning"). If anyone is interested, here are the details: https://build2.org/build2/doc/build2-build-system-manual.xht...
Re: CalVer: Calendar Versioning
#48I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…
Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.
Re: CalVer: Calendar Versioning
#49I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…
Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.
what would be a more reliable way to know?