Seems to obvious to say, but: a version numbers purpose is to let you easily determine what version of the software anyone is running.
If there is any chance of anyone having access to a particular iteration of the code, and not otherwise easily be able to determine a unique identifier, then that iteration should have a unique version number. I see this as the 'first rule'. As a consequence, distinct releases will clearly want distinct version numbers.
However, more comes into play:
One way to be sure of this is to bump version numbers with each commit but this is not usually a good idea. It may take several commits/iterations to get a relatively small change working, and it's confusing to the outside world to see version 0.0.1 -> 0.0.2 as a result of a large number of accumulated changes then 0.0.2 -> 0.0.56 because someone committed white space fixes one file at a time and didn't change anything functional.
How far down the road from "one version per full release" to "one version for each commit" is really up to: you, the other users, and what systems you're willing to use to fill the gaps.
I personally am used to working on small projects, and am happy to use git hashes until a version that others use and a bump version for each of these (no matter how few people I am expecting to get their hands on it). However in larger companies and larger projects something outside semantic version numbers, but lower fidelity than each commit, like release candidate numbering is used. These have advantages but add complexity.