I took a look at the release notes generated by JIRA and the dev-tools/release_notes.py script for 1.2.0, and noticed that it includes a lot of fixes that are also fixed in earlier versions. JIRA seems to only care about whether or not the listed fix version includes 1.2.0, disregarding whether the fix was released in an earlier version. I think this can cause release notes for a version to be very large, e.g. 2.0.0 will include lots of fixes that were already applied in 1.x.
With the previous CHANGELOG.md we sometimes listed fixes applied to multiple versions only in the earliest version containing that fix. We can do something similar with the JIRA script, by removing any issue that is resolved in an earlier released version. We'd need to mark releases as released to get this to work, but that seems doable. The downside to this type of filtering is that it means that some issues might end up hidden in release notes some users won't read. For example if we currently have 1.0.2 and 1.1.0 released, and we fix an issue in both branches, only the 1.0.3 release notes will show the bugfix. 1.1.1 doesn't show it because it was fixed in an earlier released version. Users already on 1.1.0 might not read the release notes for 1.0.3, because they're not going to downgrade, so they'll miss the bugfix. I haven't found a good heuristic for when this kind of issue should be in both release notes. Any opinions on whether we should filter the issues, or suggestions for what the rules for filtering should be?
