> However, for the node-ttl setting we are not providing a way to define the older node-ttl-days setting here, which means we're exposing a setting that was available in 1.0 but not the means to actually set it.

If we can tell what version of the module they are using, its easy enough to make this conditional. If the semantics are the same the newer node-ttl option could set node-ttl-days or node-ttl conditionally. Question is, if we expose it and don't check - and yet we claim we support 1.0 in the module and someone uses it, what happens?

> I worry that the module is going to get really hairy if we try to maintain backward compatibility too far into the past, so I think my current inclination is to simply start documenting (very prominently--at the top of the main README or similar) that certain versions of the module are only compatible with certain versions of puppetdb

@cprice-puppet I agree, we have to be clear on what version of puppetdb we support with the module. Its about being PuppetDB version focused ... not config option/feature focused.

Can we treat it like any feature and use semantic versioning and deprecation rules around this? Ie. 0.9 is now deprecated in say 2.0.5, next major release (3.0.0) its not supported any more. Keep it in line with how we support puppetdb itself would be useful, so if we are officially not releasing patches for 0.9 then the module gets deprecation messages and later unsupported?