Hotfix release note strategies - long

[carthur <carthur000 -at- sympatico -dot- ca>]

Hi to you all,

I'm looking for some ideas on a good way to divide and conquer some release documentation.

We release internal software and documentation to the system administrators that install/maintain the software. The docs are also used to some extent by the end users, so the docs are written to both expert and intermediate level users.

For a release, we typically include release notes that describe all the fixes, feature overviews, and installation guides. The software includes several components, which often have different release and build numbers, and are not always built for all releases. This is all fairly straightforward and we have a review of docs after the release to determine where we can make improvements, and what we should keep doing. Unfortunately, it is becoming very messy between releases. Between releases, we do hotfixes, which can have as few as 1-2 days for dev/document/test, or which may take while longer and require new installation docs. Since our SV&V groups cannot fully replicate the deployment environment, hotfixes are expected, and I have seen anywhere from three to 21 hotfixes over several months. Never a dull moment. 

My first question is: what would suggest for doing hotfix release notes? At present, the hotfix release notes group the defects according to component, with a list by issue number and hotfix number at the end of the document.  Do you issue a separate doc per hotfix or a cumulative doc? We've done both, but when the number of hotfixes gets past about five, the cumulative doc becomes long and confusing. I am inclined to do separate ones for each hotfix for this next release, as we now have a place in the company intranet to keep them where everyone can find and see them. The location is fully searchable.

Between releases, we also sometimes have to do new feature releases (the developers have a feature specification), which are released as hotfixes, though with more SV&V testing. There are good and sound reasons for doing it this way. Honest. So far, the feature-as-a-hotfix has been released with separate overview/installation documentation, with the separate release notes formated and numbered as part of the hotfix release. This becomes very muddy very fast when there are updates to the feature-as-a-hotfix. The alternative I am considering now is to prepare release notes for the feature-as-a-hotfix as though it was a full release, but in the 'true' hotfix items list, reference the release notes. 

My second question is: Is there a better way to handle the feature-as-a-hotfix release notes? We will continue to do overview/install docs as necessary - it is reporting the fixed software defects that is questionable.

Lastly, I realize that releasing as a 'patch' would resolve much of this, as the release number would cycle up and full release notes would apply - but that isn't an option. I will be discussing with our end users the best way to handle documents released as part of hotfixes going forward - but I would like to have more options on how we approach this. I have a feature-as-a-hotfix due in the next few weeks for the latest release.

Thanks.

Cathy


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

New from Quadralay Corporation: WebWorks ePublisher Pro! Easily create 
14 online formats, including 6 Help systems, in a project-based 
workflow. Live, online demo! http://www.webworks.com/techwr-l

Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author 
content and configure Help in MS Word or any HTML editor. No 
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.