HUGE subject, but I'll just note one element: 
>> Now I want to make changes, so it will become version 1.1. What do best practices say to do? I assume save all content, TOC, and title files as new "v1-1" files. Should I create a new "v1-1" book file into which the v1-1 content goes? Or should the book file itself be version agnostic?

I'd recommend eactly the opposite:
* Do NOT use any version-specific text in FM file names.
* DO use version-specific names in the BOOK files (as that's what the PDF will eventually be called; and renaming a PDF post-generation breaks inter-document links). Just make a copy of the previous BOOK file, rename it to the next version, and archive the old BOOK file (or not, whatever).
* Control ALL references to version in FM files with variables, that you can easily change them BOOK-wide with Import Formats (Variables only).
* OPTIONAL: Use Conditions to maintain version-specific changes: "Deprecated" and "New" are sufficient for most stuff and allow for highlighting changes in review; and if you need to note when/why, add a "Release" Condition in which you note (e.g., "[Removed in v1.1 per John Doe]" or "[Workaround no longer needed; fixed in v1.1]).
A more-complex Conditional version-tracking would require you to manage a lot more (i.e., you could end up with a nightmare of overlapping conditionality for persistent features with minor tweaks each release). If you are already doing something to archive (ZIP up and stow away, even) each version's full set of working files, it's trivial to roll back, and you do not reeally need such 'always-visible' deltas fwith a single, canonical set of working files.
Again, HUGE subject, and I onl touched on the simplest method of maintining version history and simplify review for your SMEs.

You are currently subscribed to framers as

Send list messages to

To unsubscribe send a blank email to
or visit

Send administrative questions to Visit for more resources and info.

Reply via email to