How to manage version history for multiple targets?

[TechOnTheBrain]

I welcome any experiences and ideas on how best to manage version numbering and version histories in single-sourcing situations like this:

• Target A: PDF based on table of contents 1
• Target B: PDF based on table of contents 2
• Target C: PDF based on table of contents 3
• Target D: HTML5 based on table of contents 4, which is essentially a combination of A+B+C/1+2+3

Change 1 amends a topic that affects Target A (and thus also Target D) but not B or C.
Change 2 adds a single common topic to all targets.
Change 3 amends a topic that affects B and C (and thus also D) but not A.

Can you suggest a practical way to document this kind of thing when an accurate version history is required within each document/target? I thought about using a table in a single history topic and applying conditions to the rows. But I'm not sure how well that will work and it implies that, given the added complexities in single-sourcing, it'd require even more diligence than usual to ensure the history is accurate at all times.

How do people handle this sort of thing? Or did you abandon the traditional versioning and version history approach and move to something completely different that satisfies the underlying need a different way somehow?

[SteveS]

Could you create a topic called version and have 4 version control matrices, one for each target.

Use a condition for each target (I'd imagine you'd already have this set up) and use it to include the relevant matrix (and exclude the others) in each build.

[TechOnTheBrain]

As I understand it your suggestion is close to mine, with the difference each target has its own separate version history matrix within the 'version history' topic.

On the one hand, I can see this has the advantage of being simpler and more intuitive at a glance. On the other hand, it'd often mean putting the same detail in multiple tables - which runs counter to the benefits of single-sourcing. It'd quickly become unmanageable if there were many targets in the project. Even with only 4 targets as in my example it'd be very easy to make a mistake (in either of our suggestions - mine is complicated by tricky conditions, yours is complicated by manual duplication of common entries).

Perhaps there is a fundamental and irreducible level of complexity and difficulty in maintaining version histories...

But I can't help thinking there must be a better way. Someone must've found a sensible way to tackle (or supersede) this already - surely plenty of people have had to convert document sets where careful change control and version histories must continue to be managed?