Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

(In reply to Stefan Arentz [:st3fan] from comment #1)

Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Thanks Stefan. You definitely have a point here, looks like this slipped through the cracks. The core ping is sending, through the submission URL, both the appVersion and the appBuildId. With the current schema, we'd just be sending app_build (matching with the appBuildId for the core ping).

I propose adding the following fields to the ping_info section of all the glean pings:

• app_build_id: the build number/string from the CI system (a string, e.g. "1234/A")
• app_display_version: the user visible version string (a string, e.g. "1.0.3")
• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

@Georg, Frank - What do you think? Should we consider sending this as part of the submission URL instead, as with the usual telemetry? Or it's not useful?

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

@Stefan, Do you know what kind of analyses would this support? I'm thinking that this should probably be in the metrics/baseline ping, but not in the ping_info section.

@Georg, Frank - thoughts?

(In reply to Alessio Placitelli [:Dexter] from comment #2)

(In reply to Stefan Arentz [:st3fan] from comment #1)

Couple of thoughts ... there is the user visible version (1.0.3) and also a build number from the CI system (1234). Both are very important to know.

Thanks Stefan. You definitely have a point here, looks like this slipped through the cracks. The core ping is sending, through the submission URL, both the appVersion and the appBuildId. With the current schema, we'd just be sending app_build (matching with the appBuildId for the core ping).

I propose adding the following fields to the ping_info section of all the glean pings:

• app_build_id: the build number/string from the CI system (a string, e.g. "1234/A")
• app_display_version: the user visible version string (a string, e.g. "1.0.3")

+1 to those.

• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

This is a little harder to generalize. We might want to break that out into a different bug.

Some apps (like fenix or reference browser) also have additional components with a version number. For example GeckoView or the Application Services library. We don't care too much about dependencies usually, but I think specially those two will be really interesting to be able to query in dashboards.

"Give me this report and group it by geckoview version"

@Stefan, Do you know what kind of analyses would this support? I'm thinking that this should probably be in the metrics/baseline ping, but not in the ping_info section.

@Georg, Frank - thoughts?

+1, this is not something that should generally be in the ping_info section.

We could put this into the baseline or metrics ping, depending on where it is important.

@dexter I use all three of app_build_id, app_display_version and app_release_channel in my analyses, so I'd like to see all of these metrics (likely in the baseline ping?) - but where they should live I'll leave up to you.

(In reply to Georg Fritzsche [:gfritzsche] from comment #3)

• app_release_channel (optional): the name of the release channel the application is on, if the definition applies (e.g. "beta", "release", "nightly", ...). As far as I understood, some applications don't use release channels so this field wouldn't be present for them.

This is a little harder to generalize. We might want to break that out into a different bug.

I filed bug 1520741 for that.

(In reply to Megan McCorquodale from comment #4)

@dexter I use all three of app_build_id, app_display_version and app_release_channel in my analyses, so I'd like to see all of these metrics (likely in the baseline ping?) - but where they should live I'll leave up to you.

Cool, thanks Megan!

data-review?chutten as liuche is on PTO.

This is the data-review request for adding the new appDisplayVersion field to the ping_info section of all the pings sent by glean.

The documentation is linked within the data-review request.

Everything was reviewed and merged.