I'm aware of this issue and I don't have other idea than what you suggested. I'm OK to mark released version as 'released' and only enumerating unreleased issues. It looks simplest and IMHO still less error-prone than manually editing CHANGELOG.
I guess other projects would have similar issue as well so if someone working to other projects as well sheds a light, that should be great. Maintaining major / minor / bugfix branches together would be not trivial case though. - Jungtaek Lim (HeartSaVioR) 2017년 8월 27일 (일) 오전 6:36, Stig Rohde Døssing <[email protected]>님이 작성: > 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? >
