Best practices documentation for customer maintaining Qt updateability

We need documentation on best practices, do's and don'ts for ensuring Qt updatability. This is needed by our customers, and customers customers whom are using Qt in their solutions (and Devices).

The back story: EU CRA is forcing manufactures to be able to maintain products for very long periods (perhaps 25 years), and one needs to plan that well ahead. We should provide documentation to help our customer make right choices in their implementation.

Specific example requirement / wish from our SDK customer who is making HMI display computers, is that their customers making and selling actual industrial machines need to be able to update Qt with security patches without re-building their own application. We should see if this is even possible, what would be the tradeoffs, or alternatively what should be our recommendations.

The documentation needs to cover

• Qt source and binary compliancy promises and what they mean
• Best practices on what to do if customer needs to modify Qt code
  • What parts are safer to edit than others?
  • How to forward-port things on your own
  • How to become a contributor, and get your changes to be part of Qt. And why we reject OS or HW specific contributions.
• Building apps with dynamic linking - Allows changing libraries with security updates but as tradeoff, may impact performance and open other security isssues in the solution
• Other topics that come up once RnD puts their head in to this