In SemVer should I increase the version on every commit/accepted pull request

Question

Running a community project. Have a few pull requests that have been made and the version of our product is currently 2.5.0

All 3 of the changes are feature adds but are backwardly compatible. Should I be creating 2.6.0, 2.7.0 and then 2.8.0 as I have 3 new features being added or is it common to bind together a collection of features and rev the version once.

For example, 2.6.0 will contain all 3 pull requests

I would expect it would transition as

2.6.0-RC1 ->
2.6.0-RC2 ->
2.6.0-RC3

ending with
2.6.0 (version)

I've had a look at Puppet who say they use semantic versioning but they have just merged 38 pull requests this month and I'm doubting I'll see the version going crazy. Version 2.2.0 for example seems to have a number of fixes https://github.com/puppetlabs/puppetdb/commit/d31c22ed00aa5d25b9e09403abee3a46bdecb7ef

What should I be doing as per SemVer?

Answer 1

While not being explicit about it, SemVer applies to released packages.

Therefore, if you, as release manager, build a package containing all 3 commits then you only have to increment the version once. If you choose to release them in separate packages then you have to increase the version each time you release.