On 2014-29-08 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
<mailto:da...@dasz.at>> wrote:
On 2014-08-28 00:51, Kylo Ginsberg wrote:
But going forward there's a question about how to handle changes
to fact
*values*. One proposal is that we identify (and of course test
against)
some essential facts that we "care a lot about" (such as
'lsbmajdistrelease") and set some rules, like:
(a) we do not change those in x.y.Z releases
(b) we highlight it when they DO change in x.Y or X releases
Strict semver would suggest that (major) changes to values be marked
with an increment in the major version.
There are a couple really good issues here, and I'm torn on the answers:
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.
API is really what we define it to be.
IMO, values should be included. We need to specify what a fact means -
what is is measuring, and ideally how to verify that it measures that.
We also need to specify for which platforms this applies, and for which
platforms the specification is undefined / not applicable /
experimental, or some other such status to indicate that a change can
occur at any time without breaking semver.
IMO we should also type the facts at the level of detail that the Puppet
Type system allows things to be typed (i.e. not just that it is a
string, but also that it is empty / non-empty, an enumeration, a value
range, must match a pattern etc. This is especially important if the
detailed type of the value varies between platforms.
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.
Surely, there must be some tests that validates the intended behavior.
If there are none, the the behavior is unspecified, and *that* should be
specified. Having done so entitles someone to change it on that platform.
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.
Yes, but they all need to be specified.
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.
Thoughts?
They were posted above :-)
- henrik
(And regardless, we should add a VERSIONING.md to the facter project so
we have a thought-out statement on the subject.)
Kylo
--
Kylo Ginsberg
k...@puppetlabs.com <mailto:k...@puppetlabs.com>
*Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
20-24 in San Francisco*
/Register by September 8th to take advantage of the Final Countdown
<https://www.eventbrite.com/e/puppetconf-2014-tickets-7666774529?discount=FinalCountdown>
//—//save $149!/
--
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
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CALsUZFEAkxiWg70mH7cTu3TbqSd39PwGRrr0hW3invBkC6Vrjw%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CALsUZFEAkxiWg70mH7cTu3TbqSd39PwGRrr0hW3invBkC6Vrjw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/ltr0mm%24c50%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
