We do something similar with our tool releases at work. The release notes indicate bugs that were filed on a previous release and closed with the current release, and if there are open issues what the open issues are. (Usually, it's something very obscure, otherwise it would be fixed.) We do something similar with chip errata. The errata document states which chip revisions are affected, and thus implicitly what chip revision fixes the issue.
Thus, we actually have a two tiered approach. There's the internal system(s) that tracks bugs against the actual development. So, if a bug shows up in a development version, developers and internal testers can file bugs on each other. All that noise has absolutely no business going outside the development team, as it's really just developer-to-developer communication. Then there's the customer issue tracking system. Customer-reported bugs get filed in that system, and they get their own ticket number, and it gets tied to a bug filed in the internal system. The customer bug reports are the ones we comment on in the release notes, along with any notable bugs we discovered in internal testing that customers may not have hit yet.
Disclaimer: My description above is a loose description of the processes we employ at work, and there is variation across teams and business units. It isn't intended to be rigorous. I'm only commenting on my team and teams I've worked closely with. The principle is the same, though. Our dirty laundry (the internal bug tracking system) stays internal. Externally reported bugs get tracked somewhat more opaquely, simply connecting the bug report to the release it's fixed in. It seems quite reasonable to me.