You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make it easier to find releases in the mobile insights module, add the possibility of changing the release sorting from the date created to the number of events, semantic versioning, and date adopted. It’s not set in stone which types of sorting we need to implement. We should implement the ones that are easy to do and skip the ones that require more considerable effort.
Why are we doing this?
The release selector has two main issues. First, the default selected release is the most recent one, which can be a debug or staging build with little to no data. Second, you might have to scroll quite a bit to find an adopted release with plenty of data.
While it would make sense to improve the selection of the default releases, we don't want to invest in that yet because the performance team plans on reworking the mobile insights screen. Instead of always showing two releases, we will only show one and allow users to compare data across releases with Automated Comparative Workflows, which will let developers easily compare their telemetry to understand why a particular cohort faces more errors and performance slowdowns than the baseline.
The sorting will make it easier to find the desired release, which will also slightly improve the first problem of selecting a default release cause it will be easier to find the proper release.
To make it easier to find releases in the mobile insights module, add the possibility of changing the release sorting from the date created to the number of events, semantic versioning, and date adopted. It’s not set in stone which types of sorting we need to implement. We should implement the ones that are easy to do and skip the ones that require more considerable effort.
Why are we doing this?
The release selector has two main issues. First, the default selected release is the most recent one, which can be a debug or staging build with little to no data. Second, you might have to scroll quite a bit to find an adopted release with plenty of data.
While it would make sense to improve the selection of the default releases, we don't want to invest in that yet because the performance team plans on reworking the mobile insights screen. Instead of always showing two releases, we will only show one and allow users to compare data across releases with Automated Comparative Workflows, which will let developers easily compare their telemetry to understand why a particular cohort faces more errors and performance slowdowns than the baseline.
The sorting will make it easier to find the desired release, which will also slightly improve the first problem of selecting a default release cause it will be easier to find the proper release.
This issue originates from a page in Notion.
The text was updated successfully, but these errors were encountered: