Baseline should track Safari minor versions

[romainmenke]

#132

Safari | 2 most recent major versions | Annually

Safari major versions are not the same as Chrome/Firefox major versions.
Safari ships minor versions at similar intervals as Chrome and Firefox ship major versons, these minor versions also include many platform features with each release.

By tracking Safari major versions in Baseline, web developers will get the impression that Safari is holding back the baseline and the adoption of new features.

An unbiased baseline would track major releases for Firefox and Chrome and minor releases for Safari.

---

@jensimmons This might be of interest to the Safari/WebKit teams.

[atopal]

Thank you for bringing this up @romainmenke I'll post more in a bit, but wanted to add a quick response now: The core browser set is definitely just a starting point, and not fixed. The principles are that it needs to be rooted in data about browser usage and uptake, but also take into account developer expectations and existing support in the ecosystem. It won't work for everyone all of the time, but it needs to work for most developers most of the time.

[romainmenke]

But if the focus of Baseline is on is this feature ready to learn more about? then there shouldn't be a difference between it's been in Chrome for 3 months and it's been in Safari for 3 months.

Safari just has a different versioning strategy than Chrome/Firefox. But Safari does have the same release strategy as Chrome/Firefox. All major browser vendors ship multiple times a year, and most are evergreen (not limited by OS version, over the wire download).

Safari on iOS is the exception here. It does ship frequently (more than once a year) but it is tied to the OS version.

---

It won't work for everyone all of the time, but it needs to work for most developers most of the time.

What is the it in this sentence?

[dfabulich]

All major browser vendors ship multiple times a year, and all are evergreen (not limited by OS version, over the wire download).

That's not true of iOS Safari, is it?

[romainmenke]

You are absolutely right!
I somehow thought they changed this for both macOS and iOS.

I will edit my statement. done

[atopal]

I'll say more about it in the other thread, but Baseline is not exclusively about is this feature ready to learn more about?, it's about is this feature widely available? Browser uptake matters for that and the version numbers are proxies.

When we suggested two major versions for browsers that was based on survey data indicating that's what developers map their expectations to.

It won't work for everyone all of the time, but it needs to work for most developers most of the time.

What is the it in this sentence?

The definition of Baseline, or specifically the core browser set.

[romainmenke]

I suggest we close this issue in favor of : #174 (comment)

My concerns here are also being discussed there.

[othermaciej]

From the Safari team's point of view, we consider 15.0, 15.1, 15.4, 15.5, etc to be major versions, not minor. We give minor releases numbers like 15.6.1, with a third nonzero numeric component. Safari 15.4 is the same in what type of content it may include as Chrome 112.0. Please don't judge us for our different use of version numbers.

[foolip]

This was discussed in the WebDX CG meeting yesterday. I summarized the situation and proposed that we use the last two versions in https://github.com/mdn/browser-compat-data/blob/main/browsers/safari.json, which currently means 16.4 and 16.5. Deferring to BCD means there's already a source of truth, and it can deal with future changes to versioning in any browser. @jdatapple was present and was supportive of this change.

@dontcallmedom are there meeting notes somewhere we can link to?

Please don't judge us for our different use of version numbers.

@othermaciej of course not, all browser version numbers are beautiful 😄

The discussion continues in #174 about whether 2 versions is enough, but this is a problem for all browsers.

[dontcallmedom]

@dontcallmedom are there meeting notes somewhere we can link to?

https://docs.google.com/document/d/1ree75ImLZjf60lTZ3BhCaLHygxgywr7SBXp-q0xPs8A/edit#heading=h.9w2j2taj09jl (if the group would prefer we start archiving minutes e.g. on github, we could also look into that)

[foolip]

@dontcallmedom are there meeting notes somewhere we can link to?

https://docs.google.com/document/d/1ree75ImLZjf60lTZ3BhCaLHygxgywr7SBXp-q0xPs8A/edit#heading=h.9w2j2taj09jl (if the group would prefer we start archiving minutes e.g. on github, we could also look into that)

That's where I looked, but I'm for whatever the person volunteering to scribe wants to do. Preparing minutes for GitHub is slightly more work.

[romainmenke]

if the group would prefer we start archiving minutes e.g. on github, we could also look into that

I mostly interact async through github issues, so for me at least it is really valuable to have to be able to (re-)read the minutes when responding to an issue. A link to a google doc is fine and a good signal that something was said about the issue :)

---

Happy that this was resolved :)