6 ms·

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

deathanatos 3y ago
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.)
- catdog 3y ago
  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.
nonameiguess 3y ago
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."
mostlylurks 3y ago
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.
- yencabulator 3y ago
  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.
golergka 3y ago
Because software versioning is non-linear. A security patch to a previous LTS version can be newer than a new version of the software.
travisjungroth 3y ago
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
- erik_seaberg 3y ago
  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).
  - travisjungroth 3y ago
    Nice. That makes me realize I’ve seen it as part of nightly builds. Seems like it should just be standard though.
  - t_tsonev 3y ago
    That's a pre-release and is covered by Semver.
mickael-kerjean 3y ago
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 https://demo.filestash.app/about
nablaone 3y ago
We use YEAR.SPRINT.PATCH scheme, for example 23.10.1. But this is an internal SaaS version.

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

catdog 3y ago
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.

nonameiguess 3y ago

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

mostlylurks 3y ago

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.

yencabulator 3y ago
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.

golergka 3y ago

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

travisjungroth 3y ago

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

erik_seaberg 3y ago
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).
- travisjungroth 3y ago
  Nice. That makes me realize I’ve seen it as part of nightly builds. Seems like it should just be standard though.
- t_tsonev 3y ago
  That's a pre-release and is covered by Semver.

mickael-kerjean 3y ago

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 https://demo.filestash.app/about

nablaone 3y ago

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