SGTM! On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström <[email protected]> wrote:
> Yes, I think throwing in M117, stable on Aug 30 would be even better. > > On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip Jägenstedt wrote: > >> I think the overall timeline looks great, the final removal is almost a >> year from now, after the 2023 holiday season. >> >> However, I'd like to bikeshed "Throw an exception if the trial is not >> used in Stable in M119 (Release: October 31, 2023)". This is when the >> breakage will be apparent to most users/developers, anyone who isn't paying >> attention to deprecation warnings. Oct 31 doesn't give a whole lot of time >> to figure out how origin trials work and opt into that, so I would suggest >> M117, stable on Aug 30. That's as early as seems reasonable given summer >> vacations in the northern hemisphere. >> >> WDYT Henrik, would that work just as well for you? >> >> On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss <[email protected]> wrote: >> >>> LGTM1 for that plan >>> >>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström <[email protected]> >>> wrote: >>> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 and +Andre >>>>>> Bandarra 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 <[email protected]> >>>>>> 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* >>>>>> [email protected], [email protected] >>>>>> >>>>>> *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 [email protected]. >>>>>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWJ48RfQp2KSQW%2B0HvqYh5ir%2BWLNCshmHw0kBPjo2Fhog%40mail.gmail.com.
