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/872a8fb0-4d92-470c-af8f-0153374747cbn%40chromium.org.
