My concern about that approach is it prevents us from using semver for the module itself. If we want to add new module features (rather than support for new PuppetDB features), we have no way of conveying that in the version number in a semver-compatible way. We could just do a point release, but since the forge is pretty strict on semver, that seems bad.

There's another issue, which I discussed with @cprice-puppet in person just now, which is that we have to add a variable and ini_setting for every new param now, even though it's just key-value. Some settings, like the database-related ones, have their own logic so this makes sense. But for ordinary settings, maybe it would serve users better to add some simple define for puppetdb_setting or somesuch, which just wraps ini_setting and sets the filename. Then users don't need to wait for us to get around to releasing a new version of the module, and then upgrade, to be able to take advantage of new settings. It also reduces the duplication we face now, of having to add the parameter in three places and document it in there more. The main disadvantage of this is that users have to refer to the central PuppetDB documentation for the list of available parameters, rather than the PuppetDB module docs. Personally, I think that's not so bad.

@kbarber what are your thoughts on this?