Hacker News Reader

Comment by plainOldText | Hacker News Reader

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 (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

View on HN

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?

Look at the following:

- Number of commits.

- Number of open issues.

- Number of closed issues.

- How they respond to issues.

- Are the commit messages descriptive?

- Is the codebase a mess or does it look reasonable?

yeah is 1.7 a very stable 1.x or a very immature 2.x? what is 0.7 then? and 2.0?

can't answer one and the other consistently.

it's great for compatibility level, and that's that.

Indeed, React got to version 0.14.x before the major number became 15 after a total of three years since the first public release.

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

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

It can also mean that LibA messed up their API design twice and had to break BC twice while LibB worked diligently to provide a design that nailed it at first try or spent years in 0.XX territory and only called it stable when they were certain it's stable.

I don't consider SemVer useful to compare the maturity of software components. It's not a statement about that. It's useful to get a grip on how hard it's likely to be to go from one version to the next one.

A short list of SemVer's failures to communicate project maturity: https://0ver.org/

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.

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.

Anytime I see calendar versioning I assume one or more of the following are true about the project/package:

- it is poorly maintained

- the authors are being lazy

- it's some kind of unofficial patch or build

- marketing has taken over

- nostalgia (for Windows 95?) or imitating turn of the century project marketing

I don't think there's a good reason to ever deviate from the simple [$MAJOR_CHANGES].[$NEW_FEATURES].[$PATCH]. I don't even think it needs to be formally specified (looking at you SemVer). Simple 3-tuple versioning is almost universally understood. Why fix what isn't broken?

Reply on news.ycombinator.com