3 ms·

I think versioning like 13.07.23 is better. You automatically get: - Minor version upgrade every day. - Major version upgrade every month.

dagmx 3y ago
But that forces a very specific schedule on projects and ruins the semver meaning of what a version entails. I really dislike date based versioning unless the major version is year aligned and is truly a big jump forward (like Jetbrains do it). Otherwise how do you know when a breaking change happens? Or if a version is significant or not? With 1.69.1 I know how .1 relates to .69 and to the 1.
- revskill 3y ago
  No news is good news, so it's fine to upgrade without any changes.
- aseipp 3y ago
  Calver I think is more useful for applications that get continuously developed and released, honestly. Like, whenever you are using a webapp that is just self-contained thing, semver doesn't necessarily mean much, it basically just boils down to "Big version number bump = more recent." I think this is one of the reasons programmers gets mad at like, Google Chrome or Firefox or whatever about having version number 100, but literally nobody else cares. Version numbers just fundamentally mean something different to engineers who think of "consuming programs" like they do consuming an API, versus a user, who just thinks of it as "Bigger number = more recent = good." > Otherwise how do you know when a breaking change happens? Linux is a good illustrative example of how this works. How do you know when a breaking change in Linux happens? The answer is the developers define a stable boundary (userspace) and stick to it, whether or not they use semver, and the other components are out of scope (kernel APIs). They simply have a different criterion for where the line gets drawn. This makes some people mad and some people happy, but it's not exactly new. Similarly, in most of the calver applications I've seen and used, you typically just don't do huge breaking changes, you just do gradual migrations of existing things, with warnings, rollouts, cutovers, brownouts, etc to control what happens. So the answer is "when do they happen" is "they mostly don't." The release process and guarantees are just different. Same with "is a version significant or not." How do you know if a version of Linux is significant? You go read the release notes. They come out once every 3 months, so you always know when to look. When you do calver based releases, that question just matters a whole lot less in some sense. Did a feature not get in this time by a hair? It will just get in next time, so there's no need to squeeze yourself or sweat bullets about extending your runway. Sometimes a lot of big features land in one release and sometimes they get held back. It's just how it works. I don't think calver is very good for actual programmer-facing APIs, necessarily, but it can work e.g. webapps tend to have different versioning schemes and techniques for REST APIs, so clearly semver isn't the only possible technique. It does help introduce some mechanical semantics that can be tool checked, etc. For Rust that's really useful, but for a lot of cases that isn't so relevant.
eYrKEC2 3y ago
Have you read the `semver` spec? Very small and approachable https://semver.org/ https://semver.org/ . If your project's dependencies are following semver, you can reduce your chance of dependency hell. If you want to encode the date into a semver version string it is possible https://semver.org/#spec-item-10 https://semver.org/#spec-item-10
Lev1a 3y ago
> I think versioning like 13.07.23 is better. > You automatically get: > - Minor version upgrade every day. > - Major version upgrade every month. 1. Isn't the order normally <major>.<minor>.<patch> ? 2. For sortability the order should if anything follow the ISO 8601 order. 3. Some way to optionally represent the specific rust edition used in the compiler/toolchain version would probably be a good idea. Therefore, my recommendation would be (if you'd want to actually use this instead of semver): YYYY.MM.DD(.EDITION)(-PATCH)

dagmx 3y ago

But that forces a very specific schedule on projects and ruins the semver meaning of what a version entails. I really dislike date based versioning unless the major version is year aligned and is truly a big jump forward (like Jetbrains do it). Otherwise how do you know when a breaking change happens? Or if a version is significant or not? With 1.69.1 I know how .1 relates to .69 and to the 1.

revskill 3y ago
No news is good news, so it's fine to upgrade without any changes.
aseipp 3y ago
Calver I think is more useful for applications that get continuously developed and released, honestly. Like, whenever you are using a webapp that is just self-contained thing, semver doesn't necessarily mean much, it basically just boils down to "Big version number bump = more recent." I think this is one of the reasons programmers gets mad at like, Google Chrome or Firefox or whatever about having version number 100, but literally nobody else cares. Version numbers just fundamentally mean something different to engineers who think of "consuming programs" like they do consuming an API, versus a user, who just thinks of it as "Bigger number = more recent = good." > Otherwise how do you know when a breaking change happens? Linux is a good illustrative example of how this works. How do you know when a breaking change in Linux happens? The answer is the developers define a stable boundary (userspace) and stick to it, whether or not they use semver, and the other components are out of scope (kernel APIs). They simply have a different criterion for where the line gets drawn. This makes some people mad and some people happy, but it's not exactly new. Similarly, in most of the calver applications I've seen and used, you typically just don't do huge breaking changes, you just do gradual migrations of existing things, with warnings, rollouts, cutovers, brownouts, etc to control what happens. So the answer is "when do they happen" is "they mostly don't." The release process and guarantees are just different. Same with "is a version significant or not." How do you know if a version of Linux is significant? You go read the release notes. They come out once every 3 months, so you always know when to look. When you do calver based releases, that question just matters a whole lot less in some sense. Did a feature not get in this time by a hair? It will just get in next time, so there's no need to squeeze yourself or sweat bullets about extending your runway. Sometimes a lot of big features land in one release and sometimes they get held back. It's just how it works. I don't think calver is very good for actual programmer-facing APIs, necessarily, but it can work e.g. webapps tend to have different versioning schemes and techniques for REST APIs, so clearly semver isn't the only possible technique. It does help introduce some mechanical semantics that can be tool checked, etc. For Rust that's really useful, but for a lot of cases that isn't so relevant.

eYrKEC2 3y ago

Have you read the `semver` spec? Very small and approachable https://semver.org/ https://semver.org/ . If your project's dependencies are following semver, you can reduce your chance of dependency hell. If you want to encode the date into a semver version string it is possible https://semver.org/#spec-item-10 https://semver.org/#spec-item-10

Lev1a 3y ago

> I think versioning like 13.07.23 is better. > You automatically get: > - Minor version upgrade every day. > - Major version upgrade every month. 1. Isn't the order normally <major>.<minor>.<patch> ? 2. For sortability the order should if anything follow the ISO 8601 order. 3. Some way to optionally represent the specific rust edition used in the compiler/toolchain version would probably be a good idea. Therefore, my recommendation would be (if you'd want to actually use this instead of semver): YYYY.MM.DD(.EDITION)(-PATCH)