ActivityStream.jsm lists options.{id,version,newTabURL} but I believe we only use version as part of our telemetry. nanj, any requirements on what we can/can't replace this with? If we just remove it, we still get the Firefox version and build id, e.g., 63.0a1 and 20180709100247 ?? It has been useful to be able to keep track of what we have exported by checking install.rdf.in, but it also has caused headaches when exporting uplifts. It has also been useful for user providing about:support add-on version numbers to quickly see what's the exported git repository state, but we generally can figure out that based on the firefox version/build.

Yes, telemetry only uses options.version (i.e. addon_version) here. Currently addon_version is a required field for all the AS telemetry, and the ETL jobs enforce this by ignoring those data points with the "null" addon_version. It doesn't have any requirement on its value though as long as it's not null. Indeed, this field is not of much interest for regular analytics, rather it is mostly useful for investigating issues. So we can change it to whatever format that makes more sense.

If we don't currently get the firefox buildid (but we do get the version), we can probably pass in new ActivityStream({version: Services.appinfo.appBuildID}) Or `${Services.appinfo.version}.${Services.appinfo.appBuildID}` if we need version too

Looks like hgweb doesn't allow listing the commit history of a directory, but we can get that from git gecko-dev: https://github.com/mozilla/gecko-dev/commits/master/browser/extensions/activity-stream This can help find the latest export bug to then track down the corresponding commit state of activity-stream repository.

The fix for bug 1472038 could be to use Services.appinfo.appBuildID for ping.addon_version, which currently is state.App.version, which is just options.version, which is install.rdf's em:version… which could then also fix this bug at the same time. :)

Which, finally and somehow, makes this as a dup of bug 1472038.