feat: merge latest v0.4 to master

[unnawut]

Overview

Merging v0.4.7 changes back to master to keep code branching to the minimum.

Changes

• Changelog for v0.4.7
• Sentry logging fix
• Fix for failing CI's lint_version job

Testing

N/A

[coveralls]

Coverage remained the same at 78.146% when pulling 31796a7 on v0.4 into 40616b4 on master.

[kasima]

Tried to work through merging this PR with @unnawut.

Because v0.4 is a protected branch, we couldn't update the branch by merging up from master because master didn't have the same checks passed (we think). We turned off the required checks for this branch just to do the merge up from master.

In the normal course of development with a long-running release branch, we wouldn't want to merge up from master, since we're trying to keep these changes isolated from master. This is doesn't apply here since we don't want to keep a long-running version branch for v0.4.x. However, we still want to keep the long-running version branches for v0.1, v0.2, and v0.3 protected for now.

To merge the changes from the long-running release branch into master next time, the process would look something like:

• git checkout v0.4
• git checkout -b merge-0.4.7-changes-to-master
• create a PR from merge-0.4.7-changes-to-master
  • this branch is not branch protected and allows merges from master
  • this keeps the release branch isolated

We may want to revisit the branch protection rules if we're committed to creating release branches from tags rather than using long-running branches. We could let go of the older long-running release branches.

[unnawut]

Another thing is, the previous release I did a squash merge, and we lost all the useful commits info and ended up with a blanket "Merge v0.4 to master" commit.

This time around I'd like to try the default merge to retain the commits