When do I update my version number?

It's really up to you to decide when it's appropriate to release a version, but you should be consistent about it. If you have a roadmap for your project, consider grouping multiple related features into one milestone, and bump your minor version upon completion of those features. It's also valid to just bump the minor version with each new feature.

The most important rule is that you do not introduce a breaking change to the public API without bumping the major version. The second most important rule is that you do not introduce any changes without increasing some version number. See the FAQ at https://semver.org/

If you're just fixing a bug or making a minor adjustment, bump the patch version.

How do I increment each change?

This depends on your workflow, and how you decide to differentiate versions. Generally, it makes sense to just increment by one each time, but you could go through multiple private builds before releasing a public build. It's up to you.

Note that if you're building a library or project hosted on something like npm or crates.io, you're required to change the version with each update. Understand the semver-related tools available to you for whatever language you're working in.

Note that semantic versioning does support various labels to identify testing/beta/alpha versions of your project, see rules 9 and 10.

Do I reset the version numbers?

Yes, you should reset the patch number when you bump the minor version, and you should reset the patch and minor number when you bump the major version. Otherwise you'll eventually end up with massive version numbers as your project progresses. See semver rule 11 for information on how precedence is assigned to version numbers.