3 ms·

using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...

by jokoon 5y ago

eurasiantiger 5y ago
Proper semantic versioning gives you certain guarantees. Consider you’re on v1.2.1 of some package, pinned to your requirements as ”^1.2.1”. A security issue gets fixed, v1.2.2 is released, your CI/CD can manage this upgrade automatically. A new feature is introduced, v1.3.0 is released, your CI/CD can still manage this upgrade automatically. Developers know that there are new features because the minor version was incremented. But then, some core API refactoring is done to support new integrations, which happens to break backwards compatibility. Now, v2.0.0 is released, and it is obvious to developers that something major has changed. Your CI/CD does not do this upgrade automatically.
- kashug 5y ago
  we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system? So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade. In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.
  - jeltz 5y ago
    Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.
    - jrochkind1 5y ago
      Agreed. And I definitely don't read release notes of all my dependencies, even indirect ones, every time I update any. I lock to major versions (and hope my dependencies do to for indirect dependencies), and only look at release notes if an update breaks a build.
  - kortex 5y ago
    Eh, I would contend that poorly done semver is still better than date (only) versioning. You can always have date and/or hash as part of the metadata string. As long as you are honest with your team, saying "these are a best-effort to follow semver" it's clear what you are doing. If you are sub-1.0 basically every release is a minor bump anyways.
  - jrochkind1 5y ago
    If my CI says a patch release broke my build, I think "I should figure out why, and report the bug unless it's already reported. This is a debugging task. If I can find time to do it now, it would be contributing back upstream." If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work. It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop. It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?
wadim 5y ago
I'm also a big fan of CalVer (https://calver.org/ https://calver.org/), though I think it totally depends on the context. I wouldn't want to write C++ libraries with it.
- ThePadawan 5y ago
  I find it funny that CalVer highlights Ubuntu as a good example. I like Ubuntu when it uses its CalVer versions, but if I have to look for a specific package, I still have to check which one Xenial is after looking at the apt sources.
jeltz 5y ago
For end user applications? Sure. But for libraries where API compatibility matters I think semver is superior.

using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...

by jokoon 5y ago

using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...

Proper semantic versioning gives you certain guarantees. Consider you’re on v1.2.1 of some package, pinned to your requirements as ”^1.2.1”. A security issue gets fixed, v1.2.2 is released, your CI/CD can manage this upgrade automatically. A new feature is introduced, v1.3.0 is released, your CI/CD can still manage this upgrade automatically. Developers know that there are new features because the minor version was incremented. But then, some core API refactoring is done to support new integrations, which happens to break backwards compatibility. Now, v2.0.0 is released, and it is obvious to developers that something major has changed. Your CI/CD does not do this upgrade automatically.

kashug 5y ago
we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system? So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade. In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.
- jeltz 5y ago
  Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.
  - jrochkind1 5y ago
    Agreed. And I definitely don't read release notes of all my dependencies, even indirect ones, every time I update any. I lock to major versions (and hope my dependencies do to for indirect dependencies), and only look at release notes if an update breaks a build.
- kortex 5y ago
  Eh, I would contend that poorly done semver is still better than date (only) versioning. You can always have date and/or hash as part of the metadata string. As long as you are honest with your team, saying "these are a best-effort to follow semver" it's clear what you are doing. If you are sub-1.0 basically every release is a minor bump anyways.
- jrochkind1 5y ago
  If my CI says a patch release broke my build, I think "I should figure out why, and report the bug unless it's already reported. This is a debugging task. If I can find time to do it now, it would be contributing back upstream." If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work. It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop. It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?

wadim 5y ago

I'm also a big fan of CalVer (https://calver.org/ https://calver.org/), though I think it totally depends on the context. I wouldn't want to write C++ libraries with it.

ThePadawan 5y ago
I find it funny that CalVer highlights Ubuntu as a good example. I like Ubuntu when it uses its CalVer versions, but if I have to look for a specific package, I still have to check which one Xenial is after looking at the apt sources.

jeltz 5y ago

For end user applications? Sure. But for libraries where API compatibility matters I think semver is superior.