You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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
The text was updated successfully, but these errors were encountered:
@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.
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:
…or, in a situation where two engines add support at the same time, something like:
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:
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
More information
No response
The text was updated successfully, but these errors were encountered: