Publish the list of browsers

[captainbrosset]

As a consumer of this data, if I want to list all features in a table, with browser names as columns, I need to pick one of the baseline high feature at random, to get the list of browsers. And then again, this only gives me the list of browser ids, not their names.

Could we publish a nice list somewhere in the package so I don't have to pick a feature to find the full list of browsers? Ideally, this list would look something like:

browsers = [
  { id: "chrome", name: "Chrome" },
  { id: "chrome_android", name: "Chrome on Android" },
  { id: "edge", name: "Edge" },
  { id: "firefox", name: "Firefox" },
  { id: "firefox_android", name: "Firefox on Android" },
  { id: "safari", name: "Safari" },
  { id: "safari_ios", name: "Safari on iOS" }
];

[foolip]

Should we also publish release versions and dates?

browsers = [
  {
    id: "edge",
    name: "Edge"
    releases: [
      { version: "12", date: "2015-07-29" },
      { version: "13", date: "2015-11-12" },
      /* etc */
    ]
  },
];

Putting the releases in an array as opposed to an array with the version as they key (like BCD) avoids the need for consumers to use https://www.npmjs.com/package/compare-versions to get the versions in the right order. (JavaScript iteration order puts keys that are valid array indices first, so "12" comes before "11.1".)

[captainbrosset]

In my own explorations with this, I was also using BCD, so I have the release versions and dates from there already. All I personally needed was the "core browser set" list.
But, sure, publishing the versions/dates might be useful for others.

[foolip]

Yes, #578 is the reason I suggest it.

[ddbeck]

I had a conversation with @tonypconway today about including release info web-features and specifically about being able to answer questions like:

• What browser releases support all of the Baseline 2019 features?
• Does some browser release X support all the Baseline 2019 features?

So I think we might want something like this:

browsers = [
  {
    id: "edge",
    name: "Edge"
    releases: [
      { version: "12", date: "2015-07-29", supports_feature_sets: [] },
      { version: "13", date: "2015-11-12",  },
      { version: "14", date: "2016-08-02", supports_feature_sets: ["2015"] },
      /* etc */
      { version: "18", date: "2018-10-02", supports_feature_sets: ["2015", "2016", "2017"] },
      /* etc */
      { version: "126", date: "2024-06-13", supports_feature_sets: ["2015", "2016", "2017", "…" /* etc */, "2023"] }
    ]
  },
];

There might also be need/interest in methods that filter on this. Something along the lines of:

function minRelease(browser: string, baselineLowDate: string | Temporal.PlainDate): { version: string, date: string, supports_feature_set: string[] } { … }
// minRelease("chrome", "2019")
// ⮑ { version: "79", date: "2019-12-10", /* etc. */ }

See also: https://github.com/tonypconway/calc-baseline-years

[ddbeck]

@foolip had a good question about this, when we talked earlier today. I'll try to recap here.

The question was, paraphrased: Why would we want to show this "feature sets" info? Isn't this just a convenience around finding the last release of each browser in a given calendar year?

My answer was yes, except there's a chance that that formula is more conservative than reality. If the last interoperable feature of a given year ships in a release other than the last release of the year, then other releases earlier in that calendar year also support that calendar year's feature set.

Taking the date is good approximation and what we should do initially, for ease of implementation and conservatism until the feature set is more complete, but that's not strictly what the Baseline definition implies.

a simplified, made-up example to illustrate

Suppose our core browser set consisted of browsers Alfa and Bravo, both shipping once a month. Alfa's September 2023 release is the last to contain a newly available feature (e.g., October, November, and December's releases include no newly interoperable features). Bravo's last newly interoperable feature ships in December.

In this scenario, Alfa's September, October, November, and December releases fully support the 2023 feature set, while only Bravo's December release does. A strictly date-based calculation would wrongly suggest that 3 releases don't support the full feature set, even if they in fact did.

(Unfortunately, we won't know how common this is until our coverage of web platform features is basically complete.)

[tonypconway]

In this scenario, Alfa's September, October, November, and December releases fully support the 2023 feature set, while only Bravo's December release does. A strictly date-based calculation would wrongly suggest that 3 releases don't support the full feature set, even if they in fact did.

Totally agree that this is a valid concern, as you and I discussed with Kadir last week. As we agreed, let's not let perfect be the enemy of good enough and try to maintain some momentum.

Coming back to "why do we want to publish this" - to make it easier to get the information. We can say to folks "well, you can just figure it out by traversing the data in BCD/web-features" and informally pass around code snippets that help people do that, but that creates an unnecessary barrier to discoverability, and you might end up with different providers accidentally diverging in their implementation.

We want the likes of Google Analytics, Wix, etc to be able to pick up a file or some simple methods that map each browser version to a supported BL year and WA boolean. We're trying to shorten the number of steps between "I'm interested in showing Baseline information in my tools" and "there is Baseline information in my tools". People have specifically asked for this. Ideally a static file, rather than executable code, as it can take some orgs a long time to vet 3P executable code.