<snip> > >> That's only semantic BS. The primary consumer of facter is puppet code >> writers. If the meaning of return values of something like sprintf would >> change, all hell would break loose. Why should it be different for the >> return value of $operatingsystem ? >> >> > > Preach it, Brother! > > Seriously, the spirit of semver is not well captured by splitting hairs > over what actually constitutes the "API" to which it applies. Semver is > about using version numbering that gives users of the software reliable > information regarding compatibility between versions, principally with a > view toward how that software is used by other software. Yes, Facter's > Ruby API is an aspect of that, but certainly the fact values characteristic > of various environments are, too. The values are central to how Puppet > manifests use Facter. > > Alternatively, in the spirit of hair splitting, you could argue that > because manifests do not use Facter directly, Facter has no responsibility > toward them. Instead, then, it's up to Puppet to maintain *its own* > semver obligations toward manifests, PuppetDB, etc., *including* the fact > variables characteristic of each environment that it exposes to those > consumers. No joy there. > > I think the most interesting questions here are actually about bug > compatibility and what constitutes bug. I don't think the intention of > semver includes requiring a major version bump to accompany every batch of > bug fixes. I'd argue that Facter providing a fact value inconsistent with > that fact's definition certainly does constitute a bug -- or at least, it > *did* at one time. When that bug persists for so long that a significant > body of code comes to rely on it, however, I don't think you can reasonably > call it a bug any longer. > > I totally agree with this. I'd consider facter values an API for getting values and making decisions with Puppet code (among other things). The discussion John brings up about what's a bug is really the bigger issue here, since the behavior had been defined a different way for so long. Obviously this is the type of thing we try to avoid and unfortunately just missed it this time.
I'd still like us to keep the truthiness in fact values as high (and consistent) as possible. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMto7LLq85HiT9gR49gUreFd6pnjE9zuM9UzHwpJnPauz6CAHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
