I just implemented versioning in a CMS and I read about every article about it I could find. My conclusion is that while all articles had their point and strengths, what a version is can vary widely between applications.
For example, is my app, we decided that versions would represent "committed" modifications, for example you can modify a chapter title 60 times and then publish and get only one version. For "undo" we use browser storage. We came to this solution because it is a shared collaborative editor. In the end it is very git inspired.
The other big "problem" is structure. There are things that should and should not be versionned.
My point is that a usefull version system is very tightly coupled with the business logic, and it is not just snapshot.
I recently spent multiple months building out something like this blog post describes, for a notion-like app (to replace a different versioning scheme that could do draft pages but not point in time viewing).
We ended up doing it all in typescript, or with some postgraphile shenanigans.
One of the things we missed when requirements gathering was the ability to view a table of records each at their "latest published" version.
I think this can probably be done by including a pair of tztsrange columns in the history table (one for "when was this the latest valid draft?" and one for "when was this the latest valid published version", and do a bunch of date shuffling whenever you publish a version.
We've not actually done this yet, because there are some edge cases around dependency graphs and computed columns, but for a simpler app I reckon it would work just fine.
Specifically, the change log is an information that is almost entirely unrelated to the business logic versioning. They don't have to agree even on the timestamps, the only property that relation has is that the number of changes on the change log is larger or equal to the ones on the business versioning.
(Besides, the business versioning doesn't even have to be a single one, or have a single active version at each time.)
Those extensions are often sufficient for the change log (if you add extra information on your tables). But then, they are way overkill for that.
How do you handle the 60 modifications? Do you store each in the audit log? That's what we do and use a time rollup to get the last change within a certain time range. But I feel like there's potentially better solutions.
We use an undo stack on the browser side. We realized that it was better not to share this change log between users. Also we do not persist it. But your mileage may vary depending on your needs. In an older app the undo stack was zipped and serialized in db. With zip you avoid storing too much with every character added to 5 pages of text and you do not have to work with diff's.
For example, is my app, we decided that versions would represent "committed" modifications, for example you can modify a chapter title 60 times and then publish and get only one version. For "undo" we use browser storage. We came to this solution because it is a shared collaborative editor. In the end it is very git inspired.
The other big "problem" is structure. There are things that should and should not be versionned.
My point is that a usefull version system is very tightly coupled with the business logic, and it is not just snapshot.