In that case the proposal is: - Add deprecation warning in M113 (Release: May 2, 2023) with the possibility to opt-in to the Deprecation Trial. - Throw an exception if the trial is not used in Canary/Dev/Beta in M114. - Throw an exception if the trial is not used in Stable in M119 (Release: October 31, 2023). - Let M121 be the last version where the Trial is available (Release: January 9, 2024). In other words the first version where the trial and legacy getStats API is entirely removed is M122 (Release: February 6, 2024).
On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote: > SGTM > > On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström <h...@chromium.org> wrote: > >> >> >> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote: >> >> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström <h...@chromium.org> >> wrote: >> >> OK, so deprecation warning in M113, throwing in Beta in M114 and throwing >> in Stable on M119. We can do that. >> >> >> Awesome! >> >> >> Under this less aggressive timeline, for how many more milestones would >> the Deprecation Trial span? >> >> >> How much would be needed for people to schedule the work to make the >> switch? >> >> >> If they notice the deprecation warning they would have enough time to >> migrate before the Deprecation Trial is even needed. If they don't, how >> about 3 months extra? >> >> >> >> >> I do not have any more deprecations planned on my end and I think this is >> "standalone" enough (stats being rather specific) that in my opinion it >> should not be bundled together with anything else. >> >> >> OK, cool! >> >> >> On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote: >> >> Hey Henrik! >> >> I think the general outline of the plan makes sense, but the timelines >> seem too aggressive. As we've recently seen in the track stats removal, >> there can be a time difference between the point a developer puts in the >> work to opt-in for a deprecation trial and the point in which this work >> reaches users. >> >> I think it would make sense to: >> * Add a deprecation warning in M113 and enable a Deprecation Trial. Set a >> tentative removal milestone for M119. >> * Start throwing an exception up to Beta in M114 to try and get people's >> attention >> * Broadly communicate this change is coming in multiple channels. DevRel >> folks may be able to help there. +Paul Kinlan <paulkin...@google.com> >> and +Andre Bandarra <andre...@google.com> for thoughts. >> * In parallel to the above, turn the usecounters into UKM >> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm&ss=chromium>, >> >> and try to see where most usage lies. (and try to understand if it's coming >> from libraries with longer deployment lifecycles) >> * Flip the switch (and be ready to revert) in M119 >> >> I know this is a bit longer and more work than the plan you outlined, but >> given the few fire drills we had recently, it seems better to err on the >> cautious side. >> >> Also, do you know if more removals are planned on your side? It seems >> like it'd be better to "bundle" them so that library authors only have to >> "respin" their deployment once, rather than every few milestones. >> >> >> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström <h...@chromium.org> wrote: >> >> *This deprecation is not to be confused with the track stats deprecation >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, which >> is deprecating a small subset of the modern API. This deprecation related >> to the removal of the legacy API, a different API with the same name.* >> >> *Contact emails* >> h...@chromium.org, h...@chromium.org >> >> *Specification* >> The legacy getStats() API has no spec, no official documentation and no >> web platform tests. >> >> The modern (promise-based) version of getStats() does have a spec, but >> this is a different method returning different stats objects: >> https://w3c.github.io/webrtc-stats/ >> >> There are lots of similarities between the modern and legacy APIs, >> including several metrics that are the same, but the stats report structure >> is different and the legacy API contains several "goog"-prefixed metrics or >> metrics that behave differently from the modern API. >> >> In 2019, a document was created outlining the differences between the >> legacy and modern API >> <https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing> >> which >> may still be a useful resource, but for latest information we refer to the >> modern API's spec <https://w3c.github.io/webrtc-stats/> and code search >> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h> >> . >> >> *Summary* >> WebRTC is a set of JavaScript APIs (spec >> <https://w3c.github.io/webrtc-pc/>) enabling real-time communication, >> most notably realtime audio and video for Video Conferencing in the >> browser. getStats() is an API that allow apps to measure things like >> bitrate and media quality information about the session. >> >> The history is that spec and implementations evolved so quickly that the >> API was forked into two paths: the callback-based one that only exists in >> Chromium and has no spec and the promise-based one which has both a spec >> and pretty good cross-browser compatibility support >> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned> >> . >> >> In Chromium, the legacy API has been on feature freeze for several years >> and the goal was always to deprecate and remove it, but due to high usage >> this was not a possibility. This story is finally changing: usage graphs >> <https://webrtchacks.github.io/chromestatus/?buckets=1058,1476,1402&start=2022-01-01&window=7> >> . >> >> [image: Screenshot 2023-02-16 at 13.43.40.png] >> >> According to chromestatus.com stats >> <https://chromestatus.com/metrics/feature/popularity>, >> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.0183% and >> - RTCPeerConnectionGetStats is 0.2177% of page loads. >> In other words, legacy is 8% as popular as modern. >> >> According to UMA stats, >> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.000177% and >> - RTCPeerConnectionGetStats is 0.00114% of page loads. >> In other words, legacy is 15% as popular as modern. >> >> I don't know why UMAs and chromestatus shows different orders of >> magnitude when it comes to usage, but we're roughly talking about the >> legacy API being 1/10th as popular as the modern API. I think it is time to >> add a deprecation warning to the legacy API. >> >> *Risks* >> Usage is still high and migrating from the legacy API to the modern API >> may require a significant amount of work from developers. >> >> To mitigate this, we should have a long deprecation timeline and allow >> developers to opt-in to a Deprecation Trial to get more time. >> >> *Proposal* >> Add a deprecation warning in M113 and the possibility to opt-in to a >> deprecation trial. >> Add use counts for how many of the legacy API uses do and do not use the >> deprecation trial and track this over time. >> >> In M114, start throwing an exception in Canary/Beta if attempting to use >> the legacy API outside the trial *but do not throw* in Stable yet. Give >> apps more time to sign up to the trial. >> >> In M115, gently roll out the throwing of the exception to Stable, i.e. >> from this milestone onwards apps are required to use the deprecation trial >> if they want to continue to use the legacy getStats() API. >> >> M115 is Stable on June 27. >> Set the Deprecation Trial end date to M120 / December 5, 2023. >> This gives apps paying attention to the deprecation warning ~9 months to >> migrate and apps only paying attention to exceptions on stable ~6 months to >> migrate. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit https://groups.google.com/a/ >> chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595- >> 81fb0732fa10n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc0cb62d-c0f3-40bf-b730-62aefa1fa850n%40chromium.org.
