5 ms·

Clickbait title but makes sense. Yearly versioning. Edit: -4. Touchy HN lately. You can diss Unix with toxicity but suggesting a clearly clickbait (hide the a

Clickbait title but makes sense. Yearly versioning. Edit: -4. Touchy HN lately. You can diss Unix with toxicity but suggesting a clearly clickbait (hide the actual summarizing headline in favor of "you will be surprised by this big change") is a big no-no.

calvinmorrison 3y ago
Which tells you less than a actual semver. Where did it all go wrong?
- quonn 3y ago
  It‘s not less but different. For example you immediately know how old the version is.
- theossuary 3y ago
  Calendar versioning makes way more sense for end user applications, especially those with GUIs. There isn't much concept of a non-backwards breaking change in something like libreoffice, so semver ends up trying to expose information that isn't there.
- msla 3y ago
  Semantic versions only make sense if you anticipate discontinuous breaking changes in the future, with periods of stability between. If no new version will be a breaking change, or if every new version will be breaking, it loses meaning and you might as well go date-based. (Or, if you're Linus Torvalds, completely arbitrary.)
  - JohnFen 3y ago
    > If no new version will be a breaking change, or if every new version will be breaking But the vast majority of the time, applications fall into neither of those categories.
    - msla 3y ago
      Part of my point is, if the software doesn't have a concept of "breaking change" semantic versioning makes no sense, so you might as well just use numbers that change with every release so you can easily refer to when bugs got fixed or, maybe, features got added.
      - JohnFen 3y ago
        Applications do have the equivalent of breaking change, though. Sometimes literally in the sense that file formats change, but more usually in the sense of having to relearn how to do things, or the removal of features.
- skissane 3y ago
  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.
    - 3y ago
- ahofmann 3y ago
  Semver is perfect for developers and libraries and helps a lot. In software for end users semver tells nothing most of the time.
  - deaddodo 3y ago
    SemVer is more useful in Apps if you use feeling vs strict rules. A massive UI overhaul (but without breaking features) is almost definitely a major version bump but SemVer says it's a significant minor jump (5.0->5.5), at best. The problem is that SemVer was released for libraries, where it's rationale and rules make sense. But the abstract spirit of major.minor.patch makes more sense at an application level.
    - accoil 3y ago
      If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. If a button moves, you need to learn the new location. Shortcut changes? Tough luck, your muscle memory just deleted the last hour's progress. I don't think that's useful for users though. It's best to assume that any upgrade will break something for you, so maybe optimize for new features and bug fixes (if you even need any). Which is where other version schemes can be more helpful as they can give a greater scope of the number of changes (e.g CalVer tells you how out to date you are).
      - deaddodo 3y ago
        > If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. This is just reiterating my entire point. People follow the rule/strict interpretation of the law and SemVer breaks, you should be following the spirit of the law.
        deleted 3y ago
        [deleted]
        deleted 3y ago
- jacobsenscott 3y ago
  lol. "Breaking change: all English text is rendered right to left now. In can be changed to bottom to top in the compile options. Left to right has been removed."
- throwbadubadu 3y ago
  Just read the intro of https://semver.org/ https://semver.org/ once more, maybe you notice something?
michaellarabel 3y ago
How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible.
- xcdzvyn 3y ago
  The title is definitely supposed to play on the shock factor of 24 clearly not being immediately greater than 8, and possibly the mixed reactions to some other software moving away from SemVer (Firefox switching to Chrome's scheme comes to mind) It wasn't immediately apparent to me that the new versioning scheme would be year.month/whatever, which is the real news, but it's less interesting.
  - TaylorAlexander 3y ago
    The title is a simple factual statement. I see no reason to presume the information is presented for “shock factor”.
- meragrin_ 3y ago
  > How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible. "LibreOffice Changing To Year.Month Based Versioning Scheme" is far more clear than "LibreOffice 24.2 Will Succeed LibreOffice 7.6". The only reason I clicked through to the comments is because it was not immediately clear to me why LibreOffice would choose to skip to 24.2.

calvinmorrison 3y ago

Which tells you less than a actual semver. Where did it all go wrong?

quonn 3y ago
It‘s not less but different. For example you immediately know how old the version is.
theossuary 3y ago
Calendar versioning makes way more sense for end user applications, especially those with GUIs. There isn't much concept of a non-backwards breaking change in something like libreoffice, so semver ends up trying to expose information that isn't there.
msla 3y ago
Semantic versions only make sense if you anticipate discontinuous breaking changes in the future, with periods of stability between. If no new version will be a breaking change, or if every new version will be breaking, it loses meaning and you might as well go date-based. (Or, if you're Linus Torvalds, completely arbitrary.)
- JohnFen 3y ago
  > If no new version will be a breaking change, or if every new version will be breaking But the vast majority of the time, applications fall into neither of those categories.
  - msla 3y ago
    Part of my point is, if the software doesn't have a concept of "breaking change" semantic versioning makes no sense, so you might as well just use numbers that change with every release so you can easily refer to when bugs got fixed or, maybe, features got added.
    - JohnFen 3y ago
      Applications do have the equivalent of breaking change, though. Sometimes literally in the sense that file formats change, but more usually in the sense of having to relearn how to do things, or the removal of features.
skissane 3y ago
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.
  - 3y ago
ahofmann 3y ago
Semver is perfect for developers and libraries and helps a lot. In software for end users semver tells nothing most of the time.
- deaddodo 3y ago
  SemVer is more useful in Apps if you use feeling vs strict rules. A massive UI overhaul (but without breaking features) is almost definitely a major version bump but SemVer says it's a significant minor jump (5.0->5.5), at best. The problem is that SemVer was released for libraries, where it's rationale and rules make sense. But the abstract spirit of major.minor.patch makes more sense at an application level.
  - accoil 3y ago
    If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. If a button moves, you need to learn the new location. Shortcut changes? Tough luck, your muscle memory just deleted the last hour's progress. I don't think that's useful for users though. It's best to assume that any upgrade will break something for you, so maybe optimize for new features and bug fixes (if you even need any). Which is where other version schemes can be more helpful as they can give a greater scope of the number of changes (e.g CalVer tells you how out to date you are).
    - deaddodo 3y ago
      > If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. This is just reiterating my entire point. People follow the rule/strict interpretation of the law and SemVer breaks, you should be following the spirit of the law.
      - deleted 3y ago
        [deleted]
      - deleted 3y ago
jacobsenscott 3y ago
lol. "Breaking change: all English text is rendered right to left now. In can be changed to bottom to top in the compile options. Left to right has been removed."
throwbadubadu 3y ago
Just read the intro of https://semver.org/ https://semver.org/ once more, maybe you notice something?

michaellarabel 3y ago

How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible.

xcdzvyn 3y ago
The title is definitely supposed to play on the shock factor of 24 clearly not being immediately greater than 8, and possibly the mixed reactions to some other software moving away from SemVer (Firefox switching to Chrome's scheme comes to mind) It wasn't immediately apparent to me that the new versioning scheme would be year.month/whatever, which is the real news, but it's less interesting.
- TaylorAlexander 3y ago
  The title is a simple factual statement. I see no reason to presume the information is presented for “shock factor”.
meragrin_ 3y ago
> How is the title 'clickbait'? Calling It "LibreOffice Changing To Year.Month Based Versioning Scheme" or similar just makes it longer and less immediately clear... Really I honestly fail to see how it could be considered 'clickbait' for phrasing it as simply as possible. "LibreOffice Changing To Year.Month Based Versioning Scheme" is far more clear than "LibreOffice 24.2 Will Succeed LibreOffice 7.6". The only reason I clicked through to the comments is because it was not immediately clear to me why LibreOffice would choose to skip to 24.2.