It could also depend on what you're buildung and how. Our artifacts are primarily in Java, and our build system is Maven so we use the maven generated site for documenting artifact details. Specifically talking about release notes there is the maven-changes-plugin which generates a pretty HTML report with descriptions of what has changed and links to our bugzilla bugs, from a managed xml file we keep with each project. I believe it has the ability to auto-generate such information from JIRA as well (but we don't use that). Other plugins generate reports on code coverage, dependency versions, static analysis results, making a nice neat package for all of our internal developers to see.
Edit in response to your edit ->
I think that release notes targeted at developers should contain all issues resolved with the current release. If you were targeting a set of notes toward non-technical folks (e.g. a final application instead of a library), I think that could only contain high level, functional issues that were resolved, as they wouldn't necessarily be as interested in the technical nitty gritty, just what such changes would mean for end users. I think the notes should contain a link to your issue tracker, so people can see and search for open issues (or in the non-technical case, dig deeper into closed issues), but I don't think listing open issues in your release notes is necessary, because you might always find more issues after release, and you don't want to get into a cycle of having to update your prior release notes every time. (If there is a really really big super major issue, you might warrant an update, but as a rule of thumb, I don't think it's worth it)
We currently do maintain all release notes in the same file (by version, current version at the top), because it's much easier for me trying to determine when X issue was fixed, to scroll through one page, instead of through several pages. I could see if the notes get rather long, you might break it off at a certain point and just link to older release notes, but that would be after several sets of versions. (Admittedly we're using maven sites, and we keep the site for all the previous versions as well, so we can peek back that way too).
