Conversation
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
|
So, the browsers/bun.json file in #23440 is smaller. I wonder if we really need to add every single bun release here or just those where the webkit version has been upgraded? |
caugner
left a comment
There was a problem hiding this comment.
Overall, this looks good to me, but I have some concerns with running the downloaded executable.
|
That's reasonable - we could provide this information on Bun's website as a simple GET route. This would also save CI time on your end, too. |
|
I've made https://bun.com/versions.json which would update within a day of a new Bun release. The last thing to do is to switch the WebKit version from our commit SHAs to the semver-like version number in WebKit's source. Currently this is non-trivial to do as the values aren't easily accessible with just a Bun binary. With that said, I will explore this now and find a solution. Most likely it will look like fetching the file from GitHub's api and just grepping for the values. |
In general WebKit is upgraded in modern (~past 1.5yr) Bun releases. New features or compatibility changes are also often implemented in patches, so I would say it is relevant to be collecting every release number. WebKit commits data vs Bun releases:Versions with Shared WebKit Commits:
Versions with Unique WebKit Commits:
|
|
I've updated the PR to use the GitHub API to fetch WebKit's Versioning file from Bun's fork. I wouldn't expect we'd ever run into rate limiting issues in the future with GitHub's api, since we're only ever updating at most once per release - which is not often anyway. |
Summary
Records Bun's release information. I under Bun/Oven will commit to maintaining this in the future and reasonably ensure data is accurate.
Test results and supporting details
n/a?
Related issues
Partially fixes #27599
Related to #23440