Hello Again martti, I have been drafting something like this (for your points about OS, DB, and other specs by release)... See 2 PDFs attached... one is release changes by component, and the other is component changes by release.
Let me know what you think.
When I make architectural improvements to the docops PPM sets, I have to consider the internal side (is this sustainable for our ops, am I reducing clutter without impacting customer experience) and the customer-facing external side (is this something a user can find and consume in less time and with greater comfort).
For example, when I re-architected the Change Impact Guides, it was a win-win on both fronts. Often a fix is about reducing risk of introducing errors, or improving publishing accuracy and speed. Traceability, findability too, as with the resolved defects listing we now have as a cumulative capability. For the Change Impact Guides, we had 400 duplicate pages with conflicting data in 100s of nearly identical doc sets... I simplified all that and fenced one official page per release... and also merged on-prem and SaaS into one source page per release with conditional formatting for the minor differences. These were clear operational victories that also helped our customers, partners, and support teams locate information with fewer duplicates, near-duplicates (which require work to resolve), and with improved turnaround time.
These spec guides represent a better transactional data-driven model for managing all these specs... instead of manually having someone update tables in our doc CMS, again I found conflicts where for example, 15.5 and 15.6 pages both claimed to show the official changes in 15.5. Our information strategy going forward continues to advocate removal of such duplicate entries. In short, we are looking at ways to continue to delivery greater accuracy for better SEO with more efficient engineering.
Thank you for all your good feedback as a CA Clarity PPM Community Champion to help so many others.
Damon
PPM Documentation