Skip to content
New issue

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

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

Already on GitHub? # to your account

Add changes in support status and coverage to BCD release notes #182

Closed
meyerweb opened this issue Oct 11, 2023 · 2 comments
Closed

Add changes in support status and coverage to BCD release notes #182

meyerweb opened this issue Oct 11, 2023 · 2 comments

Comments

@meyerweb
Copy link
Member

meyerweb commented Oct 11, 2023

Problem statement

The BCD release notes contain a bit of information about what changed in each release, but could include a great deal more that would make them more interesting to standards watchers, whether those are devrels at browser makers or developers in the web community.

For the moment, there are finely granular notes that list what entries were removed or added in the release. What they lack is a list of what entries changed, and in the case of web features, what that means in terms of engine coverage of the changed feature. This proposes to add that information, and optionally use the grouping that emerges from #169 to allow for topical grouping of the entries.

Proposed solutions

Consider a release note like https://github.com/mdn/browser-compat-data/releases/tag/v5.3.20, especially the “Additions” section. This indicates when a new item is added, which for web features means support in at least one engine, but it doesn’t say which engine (or engines) support the newly-added feature. Adding that could be as basic as:

css.at-rules.scope (#20844) (Chrome 118)

…or, in a situation where two engines add support at the same time, something like:

css.properties.cool-stuff (#27384) (Chrome 133, WebKit 17)

This information could certainly be more detailed and expansive if desired, but this is probably not necessary.

Status changes

Building on the above, it would be very useful to developers to be able to see what entries had support information change, along with what the change was/changes were and the current overall support situation. Going back to the first example above, suppose in a month or two, Gecko adds at-rule support. The release notes where this support was added might show this:

css.at-rules.scope (#22322) (**Firefox 124**, Chrome 118)

The marked browser is the newly-supporting browser, and the other(s) are those that already have support. These latter show the version number when support started. (If this is too complex for some reason, the older browsers could just not show a version number.)

All such changes would be listed in a new section of the release notes called “Changes”, at the same level as “Removals” and “Additions”.

Furthermore, the web feature grouping in #169 could be used to group entries in the release notes, in all three sections. One might even use summary/details structures to collapse groups, for easier viewing. That’s all more speculative and not central to this proposal, but are offered as a possible way to manage complexity for releases where there are many changes.

Task list

  • [ ]

Priority assessment

  • Effort: unknown, possibly moderate
  • Dependencies: unknown
  • Momentum: none as yet
  • Enabling learners: possibly, though this is perhaps not something for beginners
  • Enabling professionals: absolutely
  • Underrepresented topics / Ethical web: N/A
  • Operational necessities: none
  • Addressing needs of the web industry: marginally, yes

More information

No response

@Elchi3 Elchi3 mentioned this issue Oct 18, 2023
6 tasks
@Elchi3
Copy link
Member

Elchi3 commented May 31, 2024

@meyerweb @bkardell Given you recently shared https://bkardell.com/bcd-watch/, is this project proposal still relevant? Or are there better things OWD could help you with? If not, I'd close this here. Feel free to suggest things, though.

@bkardell
Copy link
Contributor

Probably not - I guess we can tentatively close it and if @meyerweb disagrees we can reopen.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants