5 ms·

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 traditiona

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.

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.