Create app.installation.id attribute

[bencehornak]

Fixes #1874

Warning

This PR must be merged together with #1951 as they are highly related, dear maintainers, please add them to the same milestone.

Changes

Added app.installation.id (the first attribute in the installation namespace), which is a unique identifier representing the installation of an application on a specific device. Its definition is more-or-less identical to the old definition of device.id, which has always identified app installations and not devices.

In #1951 I am changing the definition of device.id, so that it actually identifies the device.

For more context see #1874.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[joaopgrassi]

I think this changes makes sense given the discussion in the issue. But I think it would be better if the changes related to device would be in a separate PR. Then you can include the changelog for it as a breaking change, since it is now Opt-In.

[LikeTheSalad]

Thanks! I like the idea of using a name that better describes what we were doing with device.id. I've just added some questions on specific details, but I'm on board with the change.

[bencehornak]

I think this changes makes sense given the discussion in the issue. But I think it would be better if the changes related to device would be in a separate PR. Then you can include the changelog for it as a breaking change, since it is now Opt-In.

@joaopgrassi Thanks for your feedback! My reasoning for adding two changes to a single PR was that I see the two changes as a single transaction. If, say, the device.id changes are merged first, then the SDK users won't have any recommended fields to identify different installations until the 2nd PR with the installation.id changes are merged. If we do it other way around, for a short period of time there will be significant overlaps between the definitions of device.id and installation.id, so that would also not be ideal.

So right now I don't know, how to put the two changes in topological order given their circular dependency, but if you help me figure this out, I'm happy to split this PR into two.

[joaopgrassi]

I think this changes makes sense given the discussion in the issue. But I think it would be better if the changes related to device would be in a separate PR. Then you can include the changelog for it as a breaking change, since it is now Opt-In.

@joaopgrassi Thanks for your feedback! My reasoning for adding two changes to a single PR was that I see the two changes as a single transaction. If, say, the device.id changes are merged first, then the SDK users won't have any recommended fields to identify different installations until the 2nd PR with the installation.id changes are merged. If we do it other way around, for a short period of time there will be significant overlaps between the definitions of device.id and installation.id, so that would also not be ideal.

So right now I don't know, how to put the two changes in topological order given their circular dependency, but if you help me figure this out, I'm happy to split this PR into two.

Yes, I understand. We have been asked by users though that such bundling breaking changes with other changes such as this makes it harder for them to track breaking changes, which is also understandable. so, we have been trying recently to better identify/label breaking changes PRs to help in such cases.

I think we could still make it work to merge both of them separately. You will need approvals in both anyway and once both are good we just merge them together in the same release. We can for example, add the PRs into the same milestone.

[bencehornak]

@joaopgrassi alright, I'll restrict this PR to the new definition of device.id, and will add the new attribute to a separate PR.

[bencehornak]

Sorry folks for the delay, now I'm back from holiday!

@joaopgrassi I have extracted the changes to device.id to #1951 as you requested, this PR only contains the addition of the app.installation.id attribute.

@lmolkova, @LikeTheSalad, @bidetofevil I believe that I have addressed all of your remarks, I would appreciate your feedback on the new additions.

[LikeTheSalad]

Thank you! 🙏