On Saturday, August 30, 2014 3:10:14 AM UTC-5, David Schmitt wrote: > > Hi, > > I really like the points Eric, Wil and Henrik have brought up. Here're > some more from me. > > On 2014-08-29 23:11, Kylo Ginsberg wrote: > > [Splitting this out of the original thread which was the Facter 2.2.0 > > announcement.] > > > > On Thu, Aug 28, 2014 at 2:58 AM, David Schmitt <da...@dasz.at > <javascript:> > > <mailto:da...@dasz.at <javascript:>>> wrote: > > > > On 2014-08-28 00:51, Kylo Ginsberg wrote: > > > > > > 1) While semver clearly applies to the Facter *API*, I'm not sure if it > > provides guidance on Facter *values*. Yes, on the one hand, I could > > argue that the values are part of the Facter contract, but that seems > > like a contortion of "API". I incline toward treating semver as > API-only. > > 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. > Semver's exclusion of UIs is due to the fact that users are much, *much* > more flexible to react to changes than deployed code. > > > 2) More importantly, a strict reading of semver as applied to facts > > would tie our hands (or force more rapid majors). E.g. I add fact 'foo' > > in 3.0, and it turns out to work great on RHEL but is incoherent on, > > say, Windows. But it's now out in the wild, so if I'm completely strict > > about changes we have to leave it be until 4.0, although that may mean > > that more and more Windows users painfully write manifests around the > > 3.0 behavior. > > > I'll return here to the distinction between feature and bug: that's where I think you can find your wiggle room. As much as there is to find, anyway. > > It's roughly (hand wave) that sort of consideration that led to the idea > > floated above of define some "major" facts (and platforms) where we make > > guarantees. > > > You actually do have some room there, too, in that you could claim -- either globally or on a per-fact basis -- that Facter's behavior is well-defined only on certain specified platforms. But you can't just declare that retrospectively, not if indeed you were serious about semver in the first place. And you also need to be prepared for the fact (no pun intended) that such a position is really just a hedge. People will still be unhappy when fact values change for platforms not on the official support list, and I wouldn't blame them. > > To tie (1) and (2) together, there's a case to be made for separating > > Facter's API guarantees from its fact value guarantees, and perhaps even > > to tiering the latter. The exact details are up for discussion of > course. > > That is totally legitimate and starting a separate semver stream for the > values just underlines that they too are API (if also perhaps a > different set). > > It is legitimate from the viewpoint of Facter's semver, but it doesn't really gain any ground outside the moral superiority realm. You would end up with Puppet manifests depending on fact value semver instead of Facter semver, but you would still have the issue that you cannot change documented behavior without a major bump (in that case to the fact value semver), and you would still have the problem that any such change would break existing manifests. Moreover, having one piece of software versioned simultaneously by two independent schemes would be a nightmare on many levels. The only way I could imagine it working would be to split Facter into separate API and fact-evaluation pieces, one for each version number sequence. Even then, I cannot imagine it working very well because modules will necessarily have direct dependencies on the fact-evaluation version. You may think we have module compatibility problems now, but they're nothing compared to what we would have if you add the possibility of fact-evaluation-version incompatibility on top. > Something that can be done to ease the semver pressure is start > collecting recipes to avoid disaster when the inevitable glitch happens. > For example, if a certain fact produces garbage on a platform and fixing > it would require wide-spread changes, I think that's a straw man. If a fact implementation produces garbage on a particular system then that's a bug -- it can be fixed without a major bump. In the meantime users will not usefully rely on that fact because it's garbage. Alternatively, if a fact is not meaningful for a particular system, then it can be withdrawn altogether for that system without a major bump because it being computed at all for that system is a bug. Users cannot usefully rely on such a fact, because that would imply that it is meaningful, contrary to the assumption. Either way, the breadth of implementation changes that might be necessary to fix any particular issue is not a semver consideration. John -- 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/96dd814a-2755-4d8f-bde3-ffbad7bf2a45%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
