5 ms·

> For most of software history, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a mi

> For most of software history, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was a small patch. You could evaluate a given piece of software by name, and get a feeling for how far away version 2.0.1 was from version 2.8.0. > But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/ http://semver.org/, changes this to make a mechanistic understanding of a codebase more important than a human one. Any "breaking" change to the software must be accompanied with a new major version number. I'm about 80% sure you're mistaken on this. I don't have a spec document or an example to back me up, but I've been slinging code for almost 30 years now, and cut my professional teeth on a big Unisys mainframe. Before version numbering in software became totally subjective, they were used to indicate break/change/patch, as described in semver.org. It was later on that software projects started to move away from that, mostly shareware and desktop software in the 90s, and only recently that projects like Firefox entirely lost the plot. The reason that "semver" used to be so popular, as you note, is because it made enterprise IT manageable. Developers don't think about that much anymore though; they just expect big IT departments to roll out nightly updates and then deal with the fallout the next day. (I'm not piling on or picking a fight, I don't use Underscore, I don't have a horse in this race. I'd welcome cited corrections or opinions from even older developers.)

mbrubeck 12y ago
Every date-based Firefox update breaks compatibility with binary add-ons (ones that link to the libxul.so C++ library). According to both SevMer and traditional library versioning practices, incrementing the major version is the correct thing to do in this case. I'm not sure why you say it has "lost the plot." Application software has generally used version numbers in different ways from library software. It's tricky for products like Firefox that are both application and library.
- thaumaturgy 12y ago
  I must be missing something. I was under the impression that Mozilla was incrementing Firefox's major version number with every new release, even if new releases didn't have api changes. As described in http://jonoscript.wordpress.com/2011/07/18/its-not-about-the-version-numbers-its-about-extension-compatibility-and-long-term-support/ http://jonoscript.wordpress.com/2011/07/18/its-not-about-the... for example. Is that not the case? Is there actually some part of Firefox that other software relies on that's getting changed in not-backwards-compatible ways with every release?
  - mbrubeck 12y ago
    For normal extensions that use supported JavaScript APIs, most releases will not break any APIs. The blog post you linked to is talking about the compatibility process for these normal JS extensions. But there is a special class of extensions ("binary add-ons") that link to Firefox/libxul as a C++ library. This has been discouraged for a long time now, but still supported for legacy reasons. These extensions have full access to Firefox's internal C++ and XPCOM interfaces. Since Firefox 4, the ABI of this internal library changes with every major update, so every release is breaking for binary add-ons (except security patches, which take care not to change the ABI, and also do not increment the major version). This is mentioned briefly in the comments of the blog post you linked to. Since that blog post was written, Firefox's add-on system has changed to address this dichotomy. Non-binary add-ons new use "lax" version checking by default (a minimum Firefox version is checked, but no maximum), while binary add-ons still use "strict" versioning. This is documented here: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Interface_Compatibility https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#strictCompatibility https://developer.mozilla.org/en-US/Add-ons/Install_Manifest... [disclosure: I'm an developer at Mozilla.]
    - thaumaturgy 12y ago
      Thanks for the explanation. It cleared up some misconceptions. I'll bookmark this for future reference.
  - Alupis 12y ago
    I sort-of think it's this guys library -- so he can change the major version number whenever he wants. Heck -- the Kernel project (now) just changes versions whenever they "feel it's right", and nobody complains... API changes or not.
    - thaumaturgy 12y ago
      Yep. I wasn't arguing for or against one religion of version numbering or another, just trying to clear up some of the history of it. I wouldn't offer my opinion on version numbering anyway, since my opinion isn't worth anything. It's definitely not in my own interest to argue for sane version numbering schemes; clients pay me hourly rates to fix issues with the software they use.

mbrubeck 12y ago

Every date-based Firefox update breaks compatibility with binary add-ons (ones that link to the libxul.so C++ library). According to both SevMer and traditional library versioning practices, incrementing the major version is the correct thing to do in this case. I'm not sure why you say it has "lost the plot." Application software has generally used version numbers in different ways from library software. It's tricky for products like Firefox that are both application and library.

thaumaturgy 12y ago
I must be missing something. I was under the impression that Mozilla was incrementing Firefox's major version number with every new release, even if new releases didn't have api changes. As described in http://jonoscript.wordpress.com/2011/07/18/its-not-about-the-version-numbers-its-about-extension-compatibility-and-long-term-support/ http://jonoscript.wordpress.com/2011/07/18/its-not-about-the... for example. Is that not the case? Is there actually some part of Firefox that other software relies on that's getting changed in not-backwards-compatible ways with every release?
- mbrubeck 12y ago
  For normal extensions that use supported JavaScript APIs, most releases will not break any APIs. The blog post you linked to is talking about the compatibility process for these normal JS extensions. But there is a special class of extensions ("binary add-ons") that link to Firefox/libxul as a C++ library. This has been discouraged for a long time now, but still supported for legacy reasons. These extensions have full access to Firefox's internal C++ and XPCOM interfaces. Since Firefox 4, the ABI of this internal library changes with every major update, so every release is breaking for binary add-ons (except security patches, which take care not to change the ABI, and also do not increment the major version). This is mentioned briefly in the comments of the blog post you linked to. Since that blog post was written, Firefox's add-on system has changed to address this dichotomy. Non-binary add-ons new use "lax" version checking by default (a minimum Firefox version is checked, but no maximum), while binary add-ons still use "strict" versioning. This is documented here: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Interface_Compatibility https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#strictCompatibility https://developer.mozilla.org/en-US/Add-ons/Install_Manifest... [disclosure: I'm an developer at Mozilla.]
  - thaumaturgy 12y ago
    Thanks for the explanation. It cleared up some misconceptions. I'll bookmark this for future reference.
- Alupis 12y ago
  I sort-of think it's this guys library -- so he can change the major version number whenever he wants. Heck -- the Kernel project (now) just changes versions whenever they "feel it's right", and nobody complains... API changes or not.
  - thaumaturgy 12y ago
    Yep. I wasn't arguing for or against one religion of version numbering or another, just trying to clear up some of the history of it. I wouldn't offer my opinion on version numbering anyway, since my opinion isn't worth anything. It's definitely not in my own interest to argue for sane version numbering schemes; clients pay me hourly rates to fix issues with the software they use.