Hi @matthias, this is a great question.
First of all, I confirm that the GET /rest/api/3/issue{issueIdOrKey}?expand=changelog endpoint will return the new format (same as what we’ll return in webhooks), so you can use it for testing your changes. The only difference is that the REST API returns both old and new changelog entries, but in the webhooks, we are just going to show the new entry in the final state.
This rollout plan for Change 6 was a trade-off between the complexity of the changes consumers potentially need to make to read basically the same changelog entry with a different name versus managing both old and new changelog items in one webhook.
From these examples we see that both IssueParentAssociation and Epic Link changelog entries have the same format, except for the IssueParentAssociation entry not having the fieldId attribute, and having a different value in fieldtype. Also, the IssueParentAssociation is issue type agnostic, which means that this changelog entry cannot be used to determine if the parent is Epic, Base level, or any other type.
When it comes to Parent vs IssueParentAssociation, the format is identical.
So the only change we expect most consumers to make is just to change the field value from Epic Link/Parent to IssueParentAssociation, and it should just work (unless the consumer relies on fieldId or fieldtype).
We encourage consumers to write their code, such that it can work with both old and new changelog entries.
Please let me know if you have any concerns about this (or if you rely on fieldId and fieldtype in your Epic Link consumer). We’ve made this decision based on feedback from the internal consumers, but we’re keen to hear what our partners think about it.
Thanks,
Konstantin