How do you generate release notes?

Question

[Question]
Does anyone product release notes via an automated process? If so how. Especially with continuous integration services. Do you just use a script to parse the log files for issues fixed for that release to create the appropriate text file?

[Background]
Recently I have implemented continuous integration for my hobby projects. As part of it I have had issue tracking reporting linked into my builds. However for releases I wish to do the same thing and have it produce a release notes files similar to the nhibernate release notes.txt which I find very clean.

[Example]

Build 1.2.1

Bug Fixed:

* [ID-1] - The system doesn't accept valid usernames

Improvements:

* [ID-2] - Saving the file takes 3 minutes when it should take a few seconds.

New Features:

* [ID-3] - Allow users to refresh the page using the F5 key.

Task Completed:

* [ID-4] - Document undocumented configuration properties.

Answer 1

Generally this sort of thing is done by issue tracking software. You track every new feature, every bugfix and every enhancement, assign them to a release and then generate release notes from the descriptions.

Answer 2

You could use a tool like doxygen to do this, but it's kind of tedious to comment the way doxygen expects. I usually get these by hand.

Not sure, but wouldn't something like FogBugz also do this?

Answer 3

In my company we use bugzilla. We use the milestone to tag a bug with a specific release number. Then we generate an xml report for all the bugs with a specific milestone and we use a small script to generate the release notes out of it.

This is something that can be easily generalized to any bug tracking software, in general.

I guess it could also be tied to comments in the commit messages on your version control system. A query could be made to list all comments on the commits on verson control and then filter for all of the comments with a specific tag.

Answer 4

Assuming the developers are not privateers and are part of a team that gets assignments and does them, a list of what was done and should be part of UAT is the defacto release note. Lists of file changes and the like are irrelevant and can be trivially extracted from source control.

Since it is painfully hard to enforce a policy of developers checking in code with issue numbers in it, I don't bother. I ask about it at the code review. I also keep a list of what we are working on. The stuff that is done-done gets added to the log right before the mvn release:prepare commands are run. I then walk it over to the QA and UAT.

This is not likely to scale to hundreds of issues per week. In those cases, a more robust system is likely to be preferable.

Answer 5

If you are using maven, there is a the maven changes plugin for this purpose and producing this report could thus be easily automated in an continuous integration process.