4 ms·
Major versions are always the first number before the first decimal point. So Safari 15 and Safari 16. You can check the linked feature set repo linked in the a
by waboremo 3y ago
Major versions are always the first number before the first decimal point. So Safari 15 and Safari 16. You can check the linked feature set repo linked in the article and see that for the features, they're only checking that first group of digits. "15" "16" (sticking to the safari example).
- chrismorgan 3y agoSafari has a radically different approach to numbering to all the rest (even though it’s them that changed, not it). It’s bumping its “major” number once per year, whereas Chromium and Firefox are bumping theirs 10–12 times per year. Unless they have radically different deployment strategies, “major versions” is clearly useless as a consistent concept across browsers. But despite Safari being tied to the OS version, when you take everything together (hardware support for their OSes, OS upgrade frequency) it’s only a little different, nowhere near the 10× difference in importance of a “major version”. All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
- waboremo 3y agoMajor versions isn't a useless consistent concept because it's the strategy all browser developers use to determine when major features are added (vs bug/security fixes). Which is what Baseline is for, feature adoption. So if Safari is adding a slew of major features once per year, and Firefox 6x per year, it doesn't matter. We have a baseline of what features as developers we can now implement without worrying about which browser version supports this or that. We see the baseline, we add the feature. Last two major versions has been utilized (unofficially) by most people through Browserlist. It's been both suitable and productive.
- chrismorgan 3y agoThis is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-notes https://developer.apple.com/documentation/safari-release-not... and see. Some of the biggest features get held for the next “major” number bump, certainly, but most point releases include at least as much as most major number bumps in Firefox or Chromium. In my experience, people haven’t tended to use just “last two versions” with Browserlist: IE has normally been special-cased historically, and Safari has regularly been special-cased in some way, and Safari has actually been the salvation of the “last two versions” strategy because it dragged the baseline down to a more acceptable place, where “last two versions” of only Firefox and Chromium would regularly be disastrous. It has long been a really poorly-thought-out mechanism. The other point you’re missing is user adoption. “At least one year” for Safari is one thing, but “five weeks” for everyone else is pretty crazy when you look at actual update statistics.
- atopal 3y agoThe issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly. I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.