I just started working for a small software company. It seems each group has it's own idea what should be in the release notes we send to the customer. I would like to standardize the process so each release is easier to track and distribute. Can anyone tell me what items they include in their release notes?
Thanks Saving Changes...
Sort By:
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Brian
The release notes describe the content of the release in terms of software and documentation and the corresponding version and what has been changed with respect to previous release.
Furthermore what type of release are you delivering, major, minor or patch (this can be an indication for the test effort).
Finally it is important to identify which bugs/changes have been solved/implemented and which functions are related. Thsi wil help to determine the scope fo regression testing and identify the test scripts related
I know some people also include the test results of system testing, integration and/or unit testing as well as the installation manual to the release notes. However I consider this a part of the release delivery whereby the notes is the accompanying letter.
If you consider the release a delviery of software and the documentation will be delvered separately at the end of the project, instalation and/or operational guide and test results should be added to the release notes as well
At least be pleased that they are producing release notes; some updates we receive here from some suppliers only have verbal "notes" accompanying them, which can be unhelpful.
Hans' info is excellent; further I would also consider the style of the notes, standardising it and including guidance as to the release's criticality and/or urgency as well as the impacts on users (e.g. training may be needed on new functions).
Here are some items that I typically see in release notes. Many of these items have to do with configuration management and change control:
* Installation instructions (fresh install and upgrade)
* List of modified/new files (often with file size and date)
* Release number
* Release date
* Key contact/support contact (e-mail, phone, etc.)
* List of change requests completed
* List of bugs or problem reports closed
* List of problems and change requests still open
* For major releases, some kind of overview of the purpose and goals of the release. For minor releases, this is not necessary, because the list of changes is usually enough.
* Target implementation date (into production)
* Revised user documentation, with changes highlighted
* Training plan (if necessary); sometimes just a list of changes that impact end-users
* Data migration and back-up instructions
I have not seen a single organization with all of these elements in one document, but I have seen all of these elements in release notes at one time or another.
Consider what is important to communicate to the people who will install, support, or use the software. That is what the release notes should include. Saving Changes...
