Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CalVer: Calendar Versioning

calver.org

Post reply on HN
Print view View original

81–90 of 102 posts

Re: CalVer: Calendar Versioning

#81

Post by paulddraper »

elsurudo wrote: post #48
plainOldText wrote: post #45

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

If anything, calendar version is superior here because you can tell when it was updated (and if it follows modern conventions, techniques, etc.)

Re: CalVer: Calendar Versioning

#82

Post by paulddraper »

voidfunc wrote: post #46
plainOldText wrote: post #45

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

Everything is a library to someone.

Re: CalVer: Calendar Versioning

#84

Post by mhashemi »

eqvinox wrote: post #78
mhashemi wrote: post #73

Earlier quoted context omitted.

Why? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example. The whole point of CalVer as an alternative is that SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always c…

> Why? Why what? (I seriously don't understand what argument you're trying to make in your first paragraph.) > [...] SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems. You're forgetting to ask the question whether this bill of goods is desirable. Considering the environment we have today (frequent security update…

I was only asking why you say it comes crashing down, when the link cites multiple cases of successful parallel version maintenance with a version that is at least partially calendar-based.

As far as usability, time is a dimension no developer can escape. We develop software on a schedule and we deprecate it on a schedule. CalVer is tremendously semantic at that higher level. The semantics SemVer clings to suffer even under ecosystems which have mandated their use (go, node). The effect has been an over-granularization of APIs themselves.

I'm fine with agreeing to disagree for now. I'm also fine with the case that CalVer is not for everyone and everything. I'll leave it with this, a post seems to articulate a lot of your concerns: https://caremad.io/posts/2016/02/versioning-software/

It was written in 2016 by Donald Stufft, a maintainer of pip. Today, pip has been CalVer for a while and I'm not sure anyone has looked back. Try it sometime, and you might find the same. :)

Re: CalVer: Calendar Versioning

#85

Post by pseudalopex »

peterwwillis wrote: post #55
skrebbel wrote: post #5

Any opinions on calver vs semver for, say, open source projects or APIs/SDKs?

Semver is used for regular releases when you need to communicate deeper information to multiple consumers. A library version usually needs to communicate lots of information, to developers, to users, to distributions. Maybe this release is a dev release, while this other is stable, this release is LTS while another is not, this release has breaking changes, this one doesn't, etc. Calver is used when you don't care ab…

tzdata and several other packages in that list use dated versions because they have very strong expectations of compatibility.

Re: CalVer: Calendar Versioning

#86

Post by skissane »

eqvinox wrote: post #61

This comes crashing down in a nice mudslide the exact moment you start maintaining an older stable release for fixes while also progressing on a newer version. If anything, date codes are useful as later version number component, e.g. 4.1.0.191220. Also, the "When to use" section is getting things quite wrong: Does your project feature a large or constantly-changing scope? Large systems and frameworks, like Ubuntu an…

> SemVer gives extremely useful information here to establish how "dangerous" and update might be.

I'm doubtful about how useful the information SemVer gives really is. Someone can make massive changes to a package, rewrite half of it from scratch, add huge new features, completely redesign how parts of it are implemented, but if they don't making any breaking API changes the first version segment doesn't increment. On the other hand, someone removes some obscure feature which nobody ever used anyway, and that causes the first version segment to increment. The administrator should be much more worried about the first change than the second, but SemVer misleads them into being more worried about the second than the first.

Re: CalVer: Calendar Versioning

#87

Post by mhashemi »

joshspankit wrote: post #83

The unfortunate truth about calendar versioning is that it pushes devs and clients toward “freshness” instead of quality. Same issue that we have in Apple’s design department: change for the sake of change.

People like bigger numbers and newer releases regardless of exact versioning scheme.

SemVer makes that situation worse, by requiring a bigger major release to break some part of the API. Other failure modes detailed here: https://sedimental.org/designing_a_version.html

Re: CalVer: Calendar Versioning

#88

Post by Wowfunhappy »

pests wrote: post #70
aidenn0 wrote: post #57

Earlier quoted context omitted.

High major numbers with semver is a "stay far far away" signal for me; each major increment is a non-backwards compatible change.

Major numbers don't always match actual number of major releases. For example Java skipped from 1.4.x to 5.0.0 and React from 0.14.x to 15.0.0.

Every statistic is meaningless insofar as the statistic might be made up.

Re: CalVer: Calendar Versioning

#89

Post by sakisv »

I find this absolutely useless for libraries.

For things like Ubuntu yes, it makes sense because you wouldn't just run a command to upgrade your os.

However, your code you usually has a bunch of libraries that depends on. When I upgrade a library I don't care when the new version came out, all I care is that doesn't have breaking changes.

With semver I can get this information at a glance, calver on the other hand just says "newer version".

As others have mentioned, some combination of both approaches might give an extra data point for "freshness" especially if you're managing multiple versions, but even then what's wrong with just bumping the minor/patch?

Post reply on HN