If the classic semantic versioning scheme "MAJOR.MINOR.PATCH" makes sense, depends on to whom you deploy, and especially when and how often you deploy to the end user. The scheme is most useful if you work with stable release "4.5", where you start with as 4.5.0. The versions 4.5.1, 4.5.2, and so on contain only bug fixes, whilst you internally already work on version 4.6.
For example, if you provide a "stable branch" to your end user, give it a version 4.5.0 for the initial deployment, and 4.5.1, 4.5.2 whenever you release a patch. In your internal "agile" development and mid-sprint deployment, you can already have a version 4.6, just call it a "beta version". Whenever you deploy it in mid-sprint, add the auto-generated build number like "4.6.beta build 123". When your sprint ends, assign it "4.6.0", and switch the version number for the next sprint internally to "4.7". Starting with ".0" is only a convention, you can also use the ".0" for tagging beta-versions, and start with ".1" for your end users. IMHO the word "beta" is much more expressive, telling everyone the sprint "is not completed yet".
If you release a full end-user change log with each beta version is up to you, but at least at the end of the sprint the change log should be completed, and whenever you provide a bugfix to the end user, you should also update the history documents.
You will find the strategy of releasing two separated branches, one "stable" branch with semantic version numbers, and a "development branch" marked with build numbers or something similar, in lots of open source products like Inkscape, Firefox or 7-zip.
If, however, you do not work with separate stable and development branches, and release a new version to you end user daily, you should also increment a version number daily. For such a case, the version numbers "4.5.1", "4.5.2", ... will probably reflect your individual deployments, and do not indicate the difference between bug fixes and other changes. That can be ok, it is just not classic "semantic versioning" any more. In this scenario, you could also deploy versions 4.5, 4.6, 4.7, 4.8, that gives no real difference.
Concerning your question about entries in your changelog: IMHO when something is visible to the end user, it is worth an entry in the changelog, as soon as you deploy the change. For example, if you use feature toggles and make changes to some half-baked feature which is not activated yet to the user, that does not belong into a changelog. If you do only refactoring, with no visible change to user, that does not belong into a changelog. If you fix a bug which could have affected some users, that belongs definitely into the changelog - and it should be mentioned there at the same time when you deploy the bugfix. And it does not matter if you release daily or monthly or yearly.