Release notes should not include backports from previous versions

[jonkoops]

When a release is done the changelog is created from the release labels attacked to the issues. However when an issue is backported to an older release the new release label is still attached. For example when an issue is fixed in main the release/26.1.0 is attached, however when this issue is backported it will also receive the release/26.0.1 lablel.

This means that when a release is done for release/26.0.1 the issue is added to the changelog for that release. Then when the 26.1.0 release is done it will include the same issue in the changelog again. This is counterintuitive and should not be happening.

[stianst]

I don't personally agree with this.

Release branches are forked from main, which results in them having a life on their own, and I'd say it's better to include everything that was added since the fork happened, then just what was added since the last patch release.

Now considering if we had some sort of LTS release, that could have a lifespan beyond the next major/minor release, which would just make it even more confusing what should or should not be included in the release notes.

[jonkoops]

I think it's just very confusing to have:

26.0.1

• Fixed issue X

26.1.0

• Fixed issue X

This gives the impression that the issue wasn't fixed until 26.1.0 when I am reading the release notes This only makes sense if there are multiple supported releases at the same time receiving fixes in the form of backports.