Consider revising Subscription Edition release notes layout for BIND 9.20-S
From https://gitlab.isc.org/isc-projects/bind9/-/issues/4083#note_375252:
Oh I see - ALL the -S edition fixes and so on are at the top of the relnotes, irrespective of which version they were first added in. So if you want to know which version, you have to look at CHANGES.SE. Meh. Not sure this is fixable in any current BIND -S. Worth thinking about for 9.20-S?
Sure, I would be open to that. I agree that existing layout is arguably confusing - it's something we kept on using since 9.11.8-S1, which I believe was the first -S version prepared as a series of changes on top of the open source edition rather than a parallel branch kept in sync with the open source branch by a cherry-picking script. We just never looked back because we never got any complaints :-)
The issue with the -S edition is that there are rarely any -S-specific changes in a given release, so having a document that looks like this is kind of silly:
Release Notes for BIND 9.18.14-S1
None.
Release Notes for BIND 9.18.13-S1
None.
Release Notes for BIND 9.18.12-S1
None.
Release Notes for BIND 9.18.11-S1
None.
An idea from the other end of the spectrum would be to merge -S-specific entries with open source entries for each release. However, that muddles the split and makes rebasing a chore, so I am not particularly inclined to go with it :/
One possible compromise is to only have a section for a given -S release when it actually contains an -S-specific change. But then we'd have "holes" in the document for the releases that do not have any -S-specific changes. Also imperfect :(
Or we can go with what @tkrizek suggested and keep a single section for all -S-specific entries, but add a note to each of them that would say which version a given entry first applies to. That sounds like reasonable middle ground to me, too.
All in all, I am definitely open to changing this, but I would not like the chosen solution to trigger Git headaches for QA every time we need to rebase an -S branch (and that usually happens several times a month).