In my opinion, the second approach of having validity dates ("valid from", "valid to") is the better approach, because it allows you to easily time-limit changes. The queries for what is valid "now" are easily hidden in a view.

As an alternative approach, consider only keeping the current version in one table and the journal of changes in a secondary table. Reconstructing the old situation then consists of reading the data from the current table and reverting all changes to it from the journal, which is hard to get right. But if your concern is mostly auditing and review/selected rollback of the changes, a journal is much easier to handle in my experience.

You can set up such a journal either with database triggers (foolproof) or by copying the data in your program (less clutter in the journal, also allows for ephemeral information like "change reason", "change place in program" and "changing user", which the database doesn't necessarily know about.