TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Best Practices in Indicating Versions From:Michael West <mbwest -at- bigpond -dot- net -dot- au> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 24 Jul 2003 23:58:07 +1000
> In the old old days, documentation departments used to issue
> docs with multidigit version numbers, change bars, and change pages.
> Later, tech writers did away with change bars and relied on summary paras
> of "what's new" similar to Readme files. Then some folks did away with
> these altogether relying instead on just the date of the document. Then
> even these seem to disappear.
This narrative seems a bit elliptical to me.
Revision tracking in publications, as far as
anything I have seen, is an entirely separate
activity from the "What's New" summaries that
(traditionally anyway) describe new features
of a product. And even if someone wanted
to write a "What's New" that summarized changes
to substantive content of a "living" publication,
that would not alter the need for revision tracking
and version logging, because there is no one-to-one
correlation between substantive changes and revision
numbers. Revisions can include all manner of changes
other than substantive changes.
It seems both efficient and prudent to maintain a table
somewhere in the front matter that logs incremental
document versions with brief notations about changes
(There is no need for end-users to see any of this;
it is part of document development and can be
omitted from the final publication.)
Revision bars are useful in the development process
as well, and neither replace nor are replaced by
version control logs in any thorough and reliable
publication life-cycle. They do different things.
I hope what you describe is a local aberration
rather than a general tendency.
NEED TO PUBLISH FRAMEMAKER CONTENT ONLINE? "Mustang" is a NEW single
sourcing tool for FrameMaker that lets you easily publish your content
online. No macro language required! http://www.ehelp.com/techwr-l3
Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
