4 ms·

In general I like more the classic/old way of versioning the releases, like for example "1.2.2" which has some embedded meaning of what is changing (e.g. <major

In general I like more the classic/old way of versioning the releases, like for example "1.2.2" which has some embedded meaning of what is changing (e.g. <major_change>.<minor_change>.<bugfix>) which hints at how potentially dangerous an upgrade might be or if some new exciting stuff has been included. Jumping directly from 10 to 11 to 12 leaves me clueless without reading all release notes :(

Someone1234 7y ago
Semantic versioning is useful. Unfortunately the marketers have taken over and there's a numbers race going on.
- sroussey 7y ago
  Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
  - masklinn 7y ago
    > 2019-10 says more than 76.0.0 Neither says anything useful. 2019-10 is no more actionable or informative than 76.0.0. That 2019-10 was released in october 2019 is meaningless information and only "more" in the "babble" sense.
    - fnord123 7y ago
      2014-04 is absolutely actionable for a browser.
      - MaulingMonkey 7y ago
        2014-04 is actionable for a lot of stuff - "unpatched" or "unmaintained"...
  - lenkite 7y ago
    Well, I don't get an idea if my extension would break changing from version 2019-10 -> 2019-11 without reading the release notes. I would know it there is a big chance of breakage if I moved from 76.0.0 -> v77.0.0 and I am reasonably certain it won't break if I moved from 76.0.0 -> 76.0.1
    - diegoperini 7y ago
      But if a website breaks, you can get more idea about why it happened by comparing your current browser's calendar version to the latest update. For example, you will know you are behind x years of updates. With semantic versioning, you don't know how old you have not been updating your installation. Since there are more websites than extensions, the utilitarian approach would be to choose 2019-10 over 76.0.0.
      - lenkite 7y ago
        One approach is proactive and the other reactive. Unless, one checks the release notes every 4 weeks... I would argue the utilitarian approach is exactly the other way. Verify and test if there is an API break with a major version change. Whether the browser is 2 years or 10 years old shouldn't make a difference.
- wott 7y ago
  And this supposed marketing advantage only lasted for the first handful of releases, when numbers where under or around 10. Now numbers are so big that they have become totally insignificant. 57? 63? 98? who cares any more? Furthermore, as another comment said, it is impossible to remember on which release they started breaking this or that, since there is no more major version number change, which is usually handy to indicate backward-incompatible changes.
- nirvdrum 7y ago
  They increase the major version because they don't guarantee backward compatibility. You may think it's foolish to only provide guaranteed API support for 4 or 6 weeks, but it's more than just a marketing gimmick.
sarah180 7y ago
The reality is that you must read the release notes for this to be a strategy that can even remotely minimize your risk. On one side, relatively minor upgrades can have huge impacts for some use cases. Some changes are riskier than others, but SemVer and major/minor distinctions are not reliable signals for anything critical. More important though, if you're skipping browser updates at all, you need to be tracking the security implications of every patch you skip. Otherwise you're increasing your risk by an order of magnitude more than you'd reduce it by deciding a change might be too buggy based on a numbering scheme.
d00bianista 7y ago
Aside from versioning being clear about how big the change is, Windows Installer has this [0-255].[0-255].[0-65535] limit that I hope people do not learn about in the hard ways. It's not so fun to work around because Windows Installer tries to be smart about things, as opposed to the others that take a more robust approach. https://docs.microsoft.com/en-us/windows/win32/msi/productversion https://docs.microsoft.com/en-us/windows/win32/msi/productve...
- anticensor 7y ago
  Firefox has a custom installer.

Someone1234 7y ago

Semantic versioning is useful. Unfortunately the marketers have taken over and there's a numbers race going on.

sroussey 7y ago
Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
- masklinn 7y ago
  > 2019-10 says more than 76.0.0 Neither says anything useful. 2019-10 is no more actionable or informative than 76.0.0. That 2019-10 was released in october 2019 is meaningless information and only "more" in the "babble" sense.
  - fnord123 7y ago
    2014-04 is absolutely actionable for a browser.
    - MaulingMonkey 7y ago
      2014-04 is actionable for a lot of stuff - "unpatched" or "unmaintained"...
- lenkite 7y ago
  Well, I don't get an idea if my extension would break changing from version 2019-10 -> 2019-11 without reading the release notes. I would know it there is a big chance of breakage if I moved from 76.0.0 -> v77.0.0 and I am reasonably certain it won't break if I moved from 76.0.0 -> 76.0.1
  - diegoperini 7y ago
    But if a website breaks, you can get more idea about why it happened by comparing your current browser's calendar version to the latest update. For example, you will know you are behind x years of updates. With semantic versioning, you don't know how old you have not been updating your installation. Since there are more websites than extensions, the utilitarian approach would be to choose 2019-10 over 76.0.0.
    - lenkite 7y ago
      One approach is proactive and the other reactive. Unless, one checks the release notes every 4 weeks... I would argue the utilitarian approach is exactly the other way. Verify and test if there is an API break with a major version change. Whether the browser is 2 years or 10 years old shouldn't make a difference.
wott 7y ago
And this supposed marketing advantage only lasted for the first handful of releases, when numbers where under or around 10. Now numbers are so big that they have become totally insignificant. 57? 63? 98? who cares any more? Furthermore, as another comment said, it is impossible to remember on which release they started breaking this or that, since there is no more major version number change, which is usually handy to indicate backward-incompatible changes.
nirvdrum 7y ago
They increase the major version because they don't guarantee backward compatibility. You may think it's foolish to only provide guaranteed API support for 4 or 6 weeks, but it's more than just a marketing gimmick.

sarah180 7y ago

The reality is that you must read the release notes for this to be a strategy that can even remotely minimize your risk. On one side, relatively minor upgrades can have huge impacts for some use cases. Some changes are riskier than others, but SemVer and major/minor distinctions are not reliable signals for anything critical. More important though, if you're skipping browser updates at all, you need to be tracking the security implications of every patch you skip. Otherwise you're increasing your risk by an order of magnitude more than you'd reduce it by deciding a change might be too buggy based on a numbering scheme.

d00bianista 7y ago

Aside from versioning being clear about how big the change is, Windows Installer has this [0-255].[0-255].[0-65535] limit that I hope people do not learn about in the hard ways. It's not so fun to work around because Windows Installer tries to be smart about things, as opposed to the others that take a more robust approach. https://docs.microsoft.com/en-us/windows/win32/msi/productversion https://docs.microsoft.com/en-us/windows/win32/msi/productve...

anticensor 7y ago
Firefox has a custom installer.