I assume you are talking about 'reporting' what was done to the code at various stages.

I have yet to see the idea of program documentation outside a program succeed.

Invariably there will be differences since the fix to the program happened at a time when it was not 'convenient' to find and update the 'report'.

If you want to report (I think it just an excuse to "go back to previous" when current does not work instead of fixing current) report in two places only
1) subroutine/function headers.
2) module headers.

This way when you are programming you are, at least, close to where 'the report' should be and thus it is much more likely it will be reported.

There are two camps on this issue one will attempt to 'report' everything and the other will 'report' the bare essentials.

When I take over a project, the first I do is to remove the 'release notes' since they have absolutely no significance to me. If something is fixed it is fixed, that it was because variable123 was changed from initial value of 1 to initial value of 10 is totally uninteresting. Of course the interested parties should be informed that 'the hangup on high values problem is fixed'.

Erik

I do, of course, for the benefit of management and service, issue a 'report' for each release. This 'report' states what is fixed/added, nothing about how.