Thanks Mason, we're reaching out On Sat, May 13, 2023 at 3:27 AM Mason Freed <mas...@chromium.org> wrote:
> Chiming in briefly here - it appears (from my console messages) that > BrowserStack is currently hitting this deprecation. BrowserStack sessions > in M115 restart on ~5 second intervals with a console error pointing to > this deprecation. Might be worth reaching out to them to talk about > mitigations. > > > On Friday, February 24, 2023 at 2:28:21 PM UTC-8 Mike Taylor wrote: > >> LGTM3 >> On 2/24/23 12:31 PM, Philip Jägenstedt wrote: >> >> LGTM2, even better! >> >> On Fri, Feb 24, 2023 at 5:04 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> SGTM! >>> >>> On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström <h...@google.com> 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 <yoav...@chromium.org> >>>>> wrote: >>>>> >>>>>> LGTM1 for that plan >>>>>> >>>>>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström <hb...@chromium.org> >>>>>> 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 <hb...@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 < >>>>>>>>> hb...@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 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 <hb...@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* >>>>>>>>> hb...@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+...@chromium.org. >>>>>> 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 blink-dev+unsubscr...@chromium.org. >> >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEbRw2zV9Xz8OAknh2VECDuuiBHQus_79JMbBpuqjiDEtgmbQw%40mail.gmail.com.
