RE: PDF filenames - include release designation ?

["Margaret Cekis" <margaret -dot- cekis -at- comcast -dot- net>]

Monique:

One company where I worked that included documentation in the product's Bill
of materials used a 32-character code on every document that incorporated
the product, the software version, the document version, and the release
date. It wasn't part of the file name, but everything was cross-referenced
to it, and that number appeared on the title page, and the footers of the
rest of the document. 

As companies have dropped a lot of the formal approval processes, and
eliminated a lot of copyright and other formal legal notices from the front
matter of documents distributed online, it seems to have increased the
likelihood of confusion about what document goes with which product release,
and how users (and marketing and sales staff) verify whether they have the
right one.

Margaret Cekis, Johns Creek GA

-----Original Message-----
From: techwr-l-bounces+margaret -dot- cekis=comcast -dot- net -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+margaret -dot- cekis=comcast -dot- net -at- lists -dot- techwr-l -dot- com] On
Behalf Of Monique Semp
Sent: Wednesday, October 28, 2015 3:32 PM
To: TechWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: Re: PDF filenames - include release designation ?

> Doc revisions that occur between releases shouldn't change the version of
software that is being documented, unless the revision is part of a hotfix,
in which case the software version should also be incremented.

Yes, that's true: a doc revision doesn't change the software version. But it

does change the doc revision (in my scheme, it changes the part number final

suffix from -00 to -01, for example). And so if the sales people can't keep 
track of software version 6.3's docs and software version 6.4 docs without 
the version number in the filename, how will they possibly keep track of 
6.4, original docs vs. 6.4, first revision docs, unless that doc revision 
designation is also included in the filename?

But the consensus seems to be, include the software version. So I will. But 
I'll also have to include the doc revision designation.

> Rather than creating new branches for each release, you can tag them:
https://git-scm.com/book/en/v2/Git-Basics-Tagging

Yes, that's actually what I meant, but didn't say properly.

And although I agree that generated files (PDFs in this case) aren't 
normally stored in version control, I think it necessary when only a tech 
writer can generate the docs, but people who put together the packaging for 
a given release for a new customer have to be able to grab the appropriate 
PDFs.

Thanks, everyone,
-Monique


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

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

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives