Another angle on this ... @cprice @nicklewis ... So we can almost know what the version is today without a fact, by looking at the $puppetdb_version. However, if it is set to 'present' in the past, we are kind of stuck as it could be anything today. If its 'latest' we know its - well, the latest so whatever the 'latest' supported at the time of module release should work. This all seems a little dodgy though, as I'm guessing the majority will just not define a specific version and let if fall back to 'present'. So yeah, today - no good way to detect version.

Maybe we should just add the old parameter as an option. Ie. Add the old parameter node-ttl-days right ... saying in docs its only supported on 1.0.0 and is now deprecated if you are using 1.1.0. The new parameter is also provided, and we mention in docs it was introduced in 1.1.0. Effectively we are mapping the config to the class parameters 1 to 1 ... which is probably a reasonable approach, and it means that users familiar with our config docs can just use our class without having to do a mental mapping somewhere.

We don't have a super-great way of obviously doing proper validation on this without being certain of the puppetdb version, seems to me if we return a deprecation message in PuppetDB itself on node-ttl-days then at least we are warning _somewhere_. Do we do this today for example? If not we probably should have, or at least allow node-ttl-days to work as intended until a 2.0 release, based on semver.