8000 Expand versions returned by `getAllVersions()`, fixes refresh-downstream bug by tonypconway · Pull Request #30 · web-platform-dx/baseline-browser-mapping · GitHub
[go: up one dir, main page]

Skip to content

Expand versions returned by getAllVersions(), fixes refresh-downstream bug #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
May 12, 2025

Conversation

tonypconway
Copy link
Collaborator
@tonypconway tonypconway commented Apr 30, 2025

Expand getAllVersions() eligibility

In the wild, we see some much older browser versions in use prior to the start of Baseline in 2016 - the first year that the entire core browser set was available. We also see usage of the very latest versions either in beta/nightly states, or as the current release, but they have not yet been updated to current in @mdn/browser-compat-data or the latest version of @mdn/browser-compat-data hasn't filtered through to this module.

Consequently, it makes sense to do the following:

  • Backfill the getAllVersions() function to include all browser versions back to the earliest release of any Baseline core browser, i.e. 2002, but set the year for anything prior to Baseline 2015 as pre_baseline. We can't be sure of the feature support for these older versions without doing significantly more feature comparison work and users on browsers that old are likely to be having a fairly broken web experience anyway.
  • Change the list of acceptableStatuses to include beta and nightly.

Fix bug in refresh-downstream script

In addition, there is a version comparison bug in the refresh-downstream script that was preventing new versions from being detected. This is fixed to match the comparison behaviour in the main script.

@philipwalton
Copy link
philipwalton commented Apr 30, 2025

One more thing, when I look at the new JSON output I see stuff like this:

"1": {
  "year": "pre_baseline",
  "release_date": "2008-12-11",
  "supports": "year_only"
},

This 100% works for my use case, but it does feel a bit weird to say this browser supports "year_only" but then have the year show "pre_baseline".

What if supports was either "newly", "widely" or not set at all for cases that currently show "year_only"? This would have the advantage of also producing a smaller output. E.g.:

"1": {
  "year": "pre_baseline",
  "release_date": "2008-12-11"
},

"90": {
  "year": 2020,
  "release_date": "2021-07-13"
},

"135": {
  "year": 2024,
  "release_date": "2025-02-04",
  "supports": "widely"
},

@philipwalton
Copy link

You could potentially even omit the "year" key for cases that would currently be "pre_baseline" though I'm less keen on that since I do think there's value in communicating why there is no year set.

@tonypconway
Copy link
Collaborator Author

What if supports was either "newly", "widely" or not set at all for cases that currently show "year_only"? This would have the advantage of also producing a smaller output. E.g.:

Could do this, yes, although it makes CSV output a bit more fiddly. I agree that removing "supports: year_only" or changing it to "pre_baseline" on pre-Baseline versions is worth doing.

@tonypconway
Copy link
Collaborator Author

Hey @philipwalton and @notpushkin just FYI, this has become a bit noisy so I'm going to reduce the scope just to expanding the list of browsers in getAllVersions() and fixing the refresh-downstream bug as they are more time critical changes, and I'll explore loading strategies for the web in a separate PR. Appreciate your input!

@tonypconway tonypconway changed the title Expand versions returned by getAllVersions(), enables in-browser usage, fixes refresh-downstream bug Expand versions returned by getAllVersions(), fixes refresh-downstream bug May 12, 2025
@tonypconway
Copy link
Collaborator Author

What if supports was either "newly", "widely" or not set at all for cases that currently show "year_only"? This would have the advantage of also producing a smaller output. E.g.:

The smaller output argument is convincing here, so I've changed the logic to omit supports when it is not relevant, i.e. not "widely" or "newly". The "supports" column in the CSV will be an empty string for those browsers. Users can distinguish browsers within Baseline or not by checking if the "year" property is "pre_baseline" or an integer.

@tonypconway
Copy link
Collaborator Author

I'm calling this good to go, merging and releasing now.

@tonypconway tonypconway merged commit f87354c into main May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0