Open jonkoops opened 1 month ago
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.
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.
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
therelease/26.1.0
is attached, however when this issue is backported it will also receive therelease/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 the26.1.0
release is done it will include the same issue in the changelog again. This is counterintuitive and should not be happening.