4 ms·

I don't think semver is very useful for applications as opposed to libraries. Remove some obscure feature which almost nobody ever used? Backward incompatible

I don't think semver is very useful for applications as opposed to libraries. Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version. Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead. Makes sense to (some) developers, but to an end-user semver is rather nonsensical. Everyone can understand calendar-based versioning.

hulitu 3y ago
> Everyone can understand calendar-based versioning. Yes because it does not any meaning. Earlier major versions were reserved for adding new features, but since CADT took over the world, they just mean another version which has nothing to do with the old one.
- skissane 3y ago
  Calendar-based versioning does have meaning. If the year is 2023 and I am running WhateverApp 2010, I instantly know I am running a 13 year old version, and it is probably a good idea to see if there is a newer one-even if I’m completely happy with the 2010 version. Decent chance of new features, some of which I might find valuable; also, with every passing year, the risk of interoperability/compatibility problems (with file formats, new OS versions or versions of other applications)-even if I haven’t hit any of those problems yet Whereas, if the year is 2023 and I’m running WhateverApp 2021, that’s only a two year-old version, so absent any specific problem or missing desired feature, looking for a newer version is going to be a lower priority
JohnFen 3y ago
But semver actually tells you useful information. calendar-based versioning tells you nearly nothing. To end users who only care that they have the latest version, both schemes serve the purpose equally well, so why not go with semver? But I'll take even calendar-based over code names. Code names tell you literally nothing.
- quicklime 3y ago
  Calendar-based versioning gives a good sense of how old a version is. As an end user of LibreOffice this does a better job of helping me stay up to date, and tells me a lot more than semver - what is even the “public API” of a GUI app?
  - JohnFen 3y ago
    Semver in applications tells you important things such as how different a release is and how much incompatibility to expect. "Public API" doesn't really enter into it, but it's certainly useful to know at a glance how different the release is from the prior release. Calendar-based versioning gives you no hint of any of that. It's important to know because if it's a minor release, I'll want upgrade to it right away. If it's a bugfix release, I'll want to upgrade urgently. If there are major changes, I'll want to put it off until I have time to handle the disruption. If I have to look up how large the changes are, I'll just assume every release represents a major change and will put off upgrading until I have time to deal with it. True, semver doesn't literally tell you how old a release is, but how often is that important? What you really want to know is whether a release is newer than the one you have, and semver does tell you that.
    - kdmccormick 3y ago
      You're not describing semver, you're describing traditional feature-based versioning, which I agree is nice. This is semver: > Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version. > Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead.
      - JohnFen 3y ago
        Ah, OK. I'm using "semver" in the way I was taught it meant, but I'm totally willing to change.

hulitu 3y ago

> Everyone can understand calendar-based versioning. Yes because it does not any meaning. Earlier major versions were reserved for adding new features, but since CADT took over the world, they just mean another version which has nothing to do with the old one.

skissane 3y ago
Calendar-based versioning does have meaning. If the year is 2023 and I am running WhateverApp 2010, I instantly know I am running a 13 year old version, and it is probably a good idea to see if there is a newer one-even if I’m completely happy with the 2010 version. Decent chance of new features, some of which I might find valuable; also, with every passing year, the risk of interoperability/compatibility problems (with file formats, new OS versions or versions of other applications)-even if I haven’t hit any of those problems yet Whereas, if the year is 2023 and I’m running WhateverApp 2021, that’s only a two year-old version, so absent any specific problem or missing desired feature, looking for a newer version is going to be a lower priority

JohnFen 3y ago

But semver actually tells you useful information. calendar-based versioning tells you nearly nothing. To end users who only care that they have the latest version, both schemes serve the purpose equally well, so why not go with semver? But I'll take even calendar-based over code names. Code names tell you literally nothing.

quicklime 3y ago
Calendar-based versioning gives a good sense of how old a version is. As an end user of LibreOffice this does a better job of helping me stay up to date, and tells me a lot more than semver - what is even the “public API” of a GUI app?
- JohnFen 3y ago
  Semver in applications tells you important things such as how different a release is and how much incompatibility to expect. "Public API" doesn't really enter into it, but it's certainly useful to know at a glance how different the release is from the prior release. Calendar-based versioning gives you no hint of any of that. It's important to know because if it's a minor release, I'll want upgrade to it right away. If it's a bugfix release, I'll want to upgrade urgently. If there are major changes, I'll want to put it off until I have time to handle the disruption. If I have to look up how large the changes are, I'll just assume every release represents a major change and will put off upgrading until I have time to deal with it. True, semver doesn't literally tell you how old a release is, but how often is that important? What you really want to know is whether a release is newer than the one you have, and semver does tell you that.
  - kdmccormick 3y ago
    You're not describing semver, you're describing traditional feature-based versioning, which I agree is nice. This is semver: > Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version. > Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead.
    - JohnFen 3y ago
      Ah, OK. I'm using "semver" in the way I was taught it meant, but I'm totally willing to change.