Mention Polkadot Sdk in the release

[bkchr]

We should mention the Polkadot Sdk versions in the release notes. This will make it easier for downstream users to find out about the changes that are pulled in through the polkadot sdk.

[IkerAlus]

Ideally for users and service providers, runtime changes (f.e., a certain call is removed from a pallet) should have direct visibility in the runtime release changelog. This may be as simple as copy-pasting the relevant changes contained in the corresponding Polkadot-SDK release changelog and most likely can be automated per release.

[bkchr]

If there is a link to the Sdk release notes, I don't see any reason to duplicate this information.

[IkerAlus]

If there is a link to the Sdk release notes, I don't see any reason to duplicate this information.

This will suffice if every runtime release has a 1-to-1 correspondence with the changes in a specific Polkadot-SDK release. Will this be the case?

For example, doing a quick search I see PR1226, about removing the transfer call, in the changelogs of both Polkadot-SDK release 1.2 and 1.6. This would be confusing if there was only a link to the Polkadot-SDK notes.

[bkchr]

This will suffice if every runtime release has a 1-to-1 correspondence with the changes in a specific Polkadot-SDK release. Will this be the case?

Yes. I mean if we include these changes in a release here, than you will also see them downstream.

For example, doing a quick search I see PR1226, about removing the transfer call, in the changelogs of both Polkadot-SDK release 1.2 and 1.6. This would be confusing if there was only a link to the Polkadot-SDK notes.

This is not really related to this discussion here? If this is the case that we included things multiple times, it needs to be fixed on the SDK side and not here.

[IkerAlus]

This is not really related to this discussion here? If this is the case that we included things multiple times, it needs to be fixed on the SDK side and not here.

That is why I suggested adding specific changes to the runtime releases changelogs in my first comment. My assumption was that the Fellowship can't presuppose that SDK release changelogs are always unequivocal. But indeed, the better solution should happen at SDK side.

[bkchr]

Fixing broken release changelogs should not be done downstream and instead where they are created.

[bkchr]

This is now done as seen here: https://github.com/polkadot-fellows/runtimes/blob/main/CHANGELOG.md#based-on-polkadot-sdk