Hacker News Reader

Comment by catlover76 | Hacker News Reader

I am surprised more software libraries don't simply use date versioning. What is the reason?

It doesn't convey useful information like Semver versioning does.

(Now, why things that don't do Semver don't just do DateVer in lieu of that… IDK, really. Marketing likes to take advantage of it? …& then you get stuff like the OP here.)

At lot of projects honestly should just do something simple like date versioning, approximate pi, just increment a single number, ...

Especially those which currently use the major.minor.patch format but don't care at all about what it usually means, that in itself can be fine but using such a version scheme is then annoyingly misleading.

Dates are one dimensional, monotonic, totally non-strictly ordered. There’s no room for branching. Branching is necessary anytime you want to have multiple “latest”s. This is usually major releases with ongoing bugfixes and security updates but minimal breaking changes.

What I’ve never seen, but seems useful, is to throw the date on the version number as the third or last number. The nice thing is you get the ordering back. Something like 4.3.20231204

As I recall, Maven tooling lets you say 4.3-SNAPSHOT and creates 4.3-2023.12.04-23.27. When you release 4.3 it will be considered newer than all the snapshot versions (and other qualified versions like 4.3-beta).

Nice. That makes me realize I’ve seen it as part of nightly builds. Seems like it should just be standard though.

That's a pre-release and is covered by Semver.

With semantic versioning, it's easy to go back and provide a security update (for instance) for an earlier version of a library (which matters if the newer version is API compatible or has different dependencies or a different license or has stopped supporting the platform the user is on). If you try to do the same with date versioning, your versioning suddenly because very misleading and confusing.

The "sane" way of combining those is that the date takes the role of the major version, and this mostly applies to big projects that are pretty much guaranteed to have at least one breaking change in their twice a year release. Then you can say 2023-06-01.2 for a maintenance release on top of 2023-06-01.

Because software versioning is non-linear. A security patch to a previous LTS version can be newer than a new version of the software.

You've made it pretty hard for anything downstream to declare a dependency on a version range. They can depend on a date range, but it's not clear what basis there is for picking any particular upper bound other than "last known working version."

That's exactly what I do on my OSS work [1]: MAJOR.date. it works great for my use case (not a lib) but I don't count how many discussions I've had with people telling me: "do you know semver? You should use it"

[1]: https://demo.filestash.app/about

We use YEAR.SPRINT.PATCH scheme, for example 23.10.1. But this is an internal SaaS version.

Reply on news.ycombinator.com