I ran into this problem in every company I worked for, which 1) had a significant code base, 2) tried to get professional-quality documentation, and 3) had separate development and documentation groups.
I agreed with Anders, convinced that the software and documentation should have different version and version control systems. Although similar and having the same goal, the documentation and code have different life cycles that can be completely independent, are displayed only once at a different time of release.
As for creating documentation with every build of software, ask yourself: does this really make sense? Is the documentation historical or prescriptive? Any documentation created with each assembly has better tools for its implementation. Currently this only works for API documentation, and Doxygen / Javadoc tools exist to support this tool. This will probably never be feasible for the user guide and installation guide, as they are context sensitive.
The need for various version control systems is fulfilled, in particular, for new structured documentation methodologies. Structured documentation should be managed at a much finer level of detail than the source code in order to be able to efficiently process something even seemingly as simple as rebranding; usually controlled by either a paragraph, a sentence, or a word level, in contrast to the file level, which is enough for the source code. In addition, as a rule, it is economical that the elements of a document can be divided between several products or departments (design, marketing, etc.). And for this level of documentation complexity, only a content management system is enough to track content and manage changes; CVC- / SVN- / Perforce- / Clearcase-SCCS are incredibly inadequate for managing real documentation. Using different version control tools provides different version numbers for documentation and software.
Documentation can even have a higher rate of change than software when it considers the need to handle typos, grammar errors, and corporate identity changes.
Separation of documentation and development processes reduces dependence, which is the fundamental metric necessary to create a quality product. In addition, late binding is desirable to best take into account the fast pace of change and unpredictable events, such as late additions or deletions of functions. Only at the time of the final (or alpha / beta release) version of the documentation should be displayed on the software version. But I agree with the High-Performance Mark that the end user should not see different version numbers. The version number of the documentation should not appear in the document. This number may be maintained and hidden from the public during the documentation process.
The only time that software and documentation versions can be locked is when the documentation is a fully integrated part of the development process. Over the past 30 years, I have seen that this is getting smaller and smaller because there is a less formal, advanced design than before, relying instead on an iterative, fast prototype approach to software development. The initial good intentions regarding the development of documentation software were largely postponed, but the new methodology also did not give us improved documentation or software. Regardless of whether this documentation is done in advance or as an afterthought, it will still double the time it takes to develop a product of commercial quality.