traceability in repo changes?

[r2evans]

Thanks again for kableExtra, I'm using it weekly on dozens of reports!

I recently upgraded a woefully out-of-date (pre-1.3.1) installation to 1.3.4, and one of my reports changed (aesthetically, no errors). In trying to hunt down the change, I have isolated it to something between 1.3.1 and 1.3.2. From there, I'm running into some road blocks to figure out which git commits belong in that range. While the gist of the visual-change is not important here, my point for discussion is this:

Q: Would you considering adding some more traceability to your versions in your git repo?

Some thoughts, to various degrees of effectiveness:

• Update the NEWS.md file with relevant textual changes, commonly appended (and merged) with each commit/PR. This might preclude my need, for example, to dig deeply: if a bullet says something like "table default changes from xx to yy, use options(some.option=FALSE) to restore previous behavior", I'll know where to start looking and/or know a workaround immediately.
• Add git tags for each CRAN release. These are often annotated (git tag -a ...), but frankly something would be easier, allowing something like git diff v1.3.1 v1.3.2 to start digging in.
• (Mostly stylistic:) Use something a little more numeric than "bump version" :-P

There are likely many other options, and while I don't think that all of these are right for everybody or every project, it would be nice to have something a little more resolute.

(FYI, I can do git log -p DESCRIPTION to get close, but unfortunately Version: 1.3.2 does not appear anywhere.)

Thank you again for the package! I'm adapting another report from ztable/tableHTML to kableExtra due to its flexibility and featureset.