What's the meaning of getAllMinBaselineVersions()?

[ddbeck]

Hi @tonypconway, thanks for sharing this with me. You mentioned potentially rolling this in web-features directly. I'm amenable, but first I want to make sure I understand the use (and thus how to document) of the data this package produces.

From the example given for getAllMinBaselineVersions(), I see that this function takes a year and returns a set of browser releases. The set of releases is the first release of each browser after the end of the given year. For example, getAllMinBaselineVersions("2024") returns the last release for each browser in 2023.

The name of the function notwithstanding, I think this approximating something like: "given a year X, get the last release of each browser that definitely does not have access to any feature with a Baseline low date on after X-01-01."

Question 1: What's the application for this? Is it something you want to find the last release that still needs a polyfill/transpilation/etc.?

Question 2: Also, am I correct in assuming that you'd want the most accurate calculation of this, if web-features offered it directly? For example, suppose the first release of a browser in year X doesn't add support for any features with a Baseline year X—we ought to report that version as the new minimum version, rather than the last version of year X - 1? (e.g., the first Baseline low date of year X is not equal to the first browser release date of year X)

Mentioning web-platform-dx/web-features#578 and web-platform-dx/web-features#1047 for the back links.

[tonypconway]

Hey Daniel! This is cobbled together as a first step, it would make sense to sanitise and agree naming conventions before we roll anything into web-features. There are other structures that would be helpful here, like an all versions function that gives you an array of every version compatible with a particular cut off, and a function that dynamically gets the minimum or every version that fits that criteria.

I'm coming at this from a tools POV.

• Browserslist is relied on my most of the polyfill, bundling, linting tools that we think matter. Developers give browserslist a set of criteria - >2% global traffic, after a particular date, compatible with a particular ECMA standard, a set of minimum browser versions, etc. - and browserlist returns a list of all the version numbers for each browser that fit the criteria. Then those tools use whatever match table - caniuse-db/lite, MDN compat data, their own list - to figure do whatever they need to do.
• Analytics folks want to show tables that lump together UAs into Baseline years, so knowing either the min browser version for each year or all the versions that fit into a given year.

Baseline 2019 is all the features that were interoperable at the beginning of 2019. So a browser that is compatible with Baseline 2019 is the final release of each browser at the end of 2018 and all subsequent versions. Likewise, Baseline WA is the last release of each browser before 30 months ago, not the first release after. What we don't want to happen is tools providers to think "Baseline 2019 = 2019 browser versions and onwards", and accidentally miss out/replace features from the final 2018 releases in the case of polyfill/bundling/linting tools OR count the wrong versions for analytics providers.

I think there's a future where the dev tools folks can rely on web-features directly for this stuff, but we know that's going to take a while so I'd like to over something really speedy that browserlist can import. And analytics folks need this info, so we might as well make it easy for them to access. We could always just create a JSON files as consumables instead and just have them auto-update with a GitHub action whenever the browser files in MDN update.

Let me know what you think, we can always have a VC at some point in the next few weeks.

[ddbeck]

Baseline 2019 is all the features that were interoperable at the beginning of 2019. So a browser that is compatible with Baseline 2019 is the final release of each browser at the end of 2018 and all subsequent versions. Likewise, Baseline WA is the last release of each browser before 30 months ago, not the first release after. What we don't want to happen is tools providers to think "Baseline 2019 = 2019 browser versions and onwards", and accidentally miss out/replace features from the final 2018 releases in the case of polyfill/bundling/linting tools OR count the wrong versions for analytics providers.

I get it now! 💡 Apparently, I have a little terminology problem on my hands.

(If this is too much text, let me know—we can totally book a call.)

Within web-features, we have been referring to Baseline features and features have a date on which they became Baseline¹. We've been saying that a feature is "Baseline <year>" in the year that it reached Baseline status, not the year following. That is to say, if a feature became interoperable in October of 2022, then it would be a "Baseline 2022 feature." Collectively, the "Baseline 2022 features" would be all of the features that became interoperable between 1 January and 31 December 2022.

Which is to say, we've somehow found our way to the completely opposite conclusion than you did, about when a Baseline year is established. I'd have said "Baseline 2019 is all the features that were interoperable at the end of 2019." This is would be closer to "2020 browser versions and onwards" though that's more conservative than reality².

Because we have so far been feature oriented, on the web-features side we haven't really talked about "Baseline browsers" (except, rarely, to refer to the "core browser set" but that's not a version-specific set). We don't have established terminology for the set of releases that support a given set of Baseline features. If pressed, I'd probably be cautious to say something like "release X supports Baseline <year>."

I think there's a future where the dev tools folks can rely on web-features directly for this stuff, but we know that's going to take a while so I'd like to over something really speedy that browserlist can import.

Yes, definitely. For my part, I can push a bit more on including browser data in web-features and some methods. That's the easy part. The hard part I think is making sure we're communicating the right thing to tools authors. My preference would be to become more feature oriented, something like this:

If you want to target the Baseline 20XY feature set, then consume this: <set of releases>.
If you want to target the widely-available Baseline feature set, then consume this: <probably bigger set of releases>.

That is, if we're going to some day encourage tools authors to select from the menu of features shown in web-features, we should set them up to start thinking about releases and release dates as an implementation detail.

---

¹ In our spec for Baseline and almost nowhere else, we call this the keystone date.

² Strictly speaking, it would be "every 2020 release, plus the several releases in 2019 which include the last-implemented newly-interoperable feature." Depending on the order in which browsers shipped all of the newly interoperable features, it could potentially include releases across much of the year.

[tonypconway]

Apparently, I have a little terminology problem on my hands.

I think most of us have only really wrapped our heads around this recently.

If you want to target the Baseline 20XY feature set, then consume this: .
If you want to target the widely-available Baseline feature set, then consume this: .

Yes, agreed that this is the right way to talk about this. Only nitpick is that the set of releases will be larger if you're choosing a Baseline year >30 months in the past. If you determine from your analytics that some significant proportion of your userbase is on Safari 12 i.e. a browser compatible with the Baseline 2019 feature set (I've had partners raise this concern based on their analytics), you'll want a list of all versions from the final 2018 release of each browser onwards, which is bigger than the last 30 months.

Similarly, some regions have a consistent ~2.5% of users on Android 6.0, which only supports up to Chrome 106 (see Fyrd/caniuse#3518 (comment) for more detail on this). Chrome 106 came out in Sep 2022, so it supports Baseline features up to Sep 2022. But if you're trying to determine a simple, single config year to plug into your tooling, you'd probably need to put it into the 2021 bucket, unless we can do the more sophisticated version that you're suggesting.

If it's possible to cook up a set of methods that give you "browser versions that support the full Baseline 2019 feature set" using a feature-by-feature process, that would be awesome! But I guess that depends heavily on us completely filling out the data set, which is going to take some time.

So how about for now we expose methods or a data set that define "browsers that support the 2019 feature set" as "final release of each browser from 2018 onwards" because we know for sure that that is true and shouldn't actually make much of a difference to the tools that depend on browserslist, as they'll ultimately be referring to the same feature set?

And then as we fill out the full data set, we can update the methods to include the edge cases where we previously said Chrome XX released in December 20YY was compatible with Baseline YY+1, but we can now determine that actually Chrome XX-5 released in July 20YY fits the bill, which will give Analytics providers a more accurate estimation.

I have good availability tomorrow and Thursday PM, send me an email if you want to chat directly :-)

[ddbeck]

OK, I think we're pretty much on the same page, in terms of what we should do in the near term and what we ought to aspire toward.

I have one concern about this:

So how about for now we expose methods or a data set that define "browsers that support the 2019 feature set" as "final release of each browser from 2018 onwards" because we know for sure that that is true and shouldn't actually make much of a difference to the tools that depend on browserslist, as they'll ultimately be referring to the same feature set?

I worry that we'll create a weird double numbering system. Right now, MDN puts a year on newly available features. For example, popover looks like this, since it became interoperable in April of 2024:

But if we take "Baseline 2019 browsers" to mean the "final release of each browser from 2018 onwards" then some releases in that set won't support "Baseline 2019 features." That is to say, "Baseline 2019 browsers" and "Baseline 2019 features" would actually represent two different calendar years. We'd have this map:

• Baseline 2019 browsers → browsers at least as capable as those that shipped in late 2018
• Baseline 2019 features → features that shipped in 2019

I think that might be confusing and we should opt instead for:

• Baseline 2019 browsers → browsers that support every feature that became Baseline low in 2019 (i.e., browsers that shipped in late 2019 or more recently)
• Baseline 2019 features → features that became Baseline low in 2019

(And I just sent you a calendar invite, to talk more about this. 🙂)

[atopal]

I think that might be confusing and we should opt instead for:

• Baseline 2019 browsers → browsers that support every feature that became Baseline low in 2019 (i.e., browsers that shipped in late 2019 or more recently)
• Baseline 2019 features → features that became Baseline low in 2019

That also matches my intuitive understanding of what it means to target Baseline 2019: I want features in Baseline 2019 and have to pick the browsers to make that possible, that is: the last version of each browsers in 2019 and newer (roughly).

[tonypconway]

This definitely makes more sense, you're right. I've tweaked the logic so that the versions that are returned for e.g. Baseline 2019 are the final versions of each browser in that year.

[ddbeck]

Thank you, Tony! I'll close this up now and carry on with the work of getting web-features to do more of this, as well.