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 <yoavwe...@chromium.org> wrote: > LGTM1 for that plan > > On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström <h...@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 <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/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/CAARdPYepb3Pi7ZLiggVsy%3DuNMt8QWmNfzyLqRTUTGSmn%3Da1C1A%40mail.gmail.com.
