Is there any sort of guidelines or best practices on how release notes should be written? I guess I am trying to find the proper balance between making the point without being too specific. Also, do developer usually provide a much more release notes for QA team compare to the one submitted for public view?
How should release notes be written?
44.8k Views Asked by DeFiNite At
7
There are 7 best solutions below
0
On
Main contributor of Release Notes would be your development team. It's a good practice to allow your developers and testers to capture any release notes related information against your workItems that is linked to changesets in TFS.
Then you can use open source project like http://tfschangelog.codeplex.com to generate release notes. It has GUI version and a command line version which makes it easy to schedule your release notes reports on a nightly basis.
5
On
I find that ReleaseNotesHub works great. It provides best practice for the generation and publication of release notes.
0
On
If you have an project-management/issue-tracking system, you should definitely be using that to generate your release notes. Trac and Redmine in particular are very good at this.
Release points should have a few properties, IMO:
- Remember your audience. If this is an iPhone app, few are going to care about the fact that a particular logic error on line 572 in the Foo class was fixed. But they'll care a lot about "app is now accelerometer-sensitive".
- Summarize the new developments, features, and bugfixes in a broad, sweeping way if possible. If you can tie these together thematically (e.g. "we implemented generics and anonymous types"), a short blurb about that is a good way to give people the big picture.
- Itemize the specific things that were fixed, with links to your public bug-tracker, if any. This can usually be automatically generated.
- Don't provide excruciating detail. One- or two-liner summaries of each thing that was added or fixed should be sufficient.
- Always include specific release identifiers (e.g. "v.1.4.5"), as appropriate.
0
On
It really depends on the audience. For technical users (for example developers who use your API) you can be very technical. On the other end high-level end users of an application you created might only be interested in new features and major changes.
In between are non-technical users who need the details too, for example support department. For those people you can give a detailed description without the low level technical specifics, for example "Fixed a bug where the record wasn't saved in the database.".
0
On
One best practice with release notes in my opinion is automation. If there are certain best practices for revision control system submit messages (http://drupal.org/node/52287), you can create release notes by an automated script (http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs-release-notes/). This would create realy nice release notes: http://drupal.org/node/226165
Public release notes should contain at least:
QA release notes should contain at least:
Consider your audience and try to think what they need.
An other thing to add is new or discontinued support for certain platforms. (For example we quit support for Win3.1 and added Vista 64 bit).