On Mon, Dec 17, 2012 at 9:24 AM, Jeff McCune <[email protected]> wrote:
> This is a great discussion, please keep it up! > > On Sunday, December 16, 2012, Alex Harvey wrote: > >> >> >> On Monday, December 17, 2012 5:55:30 PM UTC+11, James Polley wrote: >> >>> >>> My reading is that, even if this is just a bugfix, the fact that it's >>> backwards-incompatible requires a major version bump. >>> >> >> Well, without a documented API you could argue that all bugfixes are >> backwards-incompatible changes. A backwards incompatible change is a >> change to the public API, as you've noted. In this case the fact in >> question is apparently supposed to count logical CPUs whereas in reality it >> counts CPU cores on Solaris. >> > > This is true, but even without a documented API we can make changes that > we have a high degree of confidence are backwards compatible. I struggle > with this issue all the time and simply try and make a best effort to > minimize the disruption to the end user who upgrades. Often this is the > best we can do. > > For our part, we're currently working to document as much of the public > Facter API as possible. Please see Patrick's pull request from last week. > > The documentation so far is for the programming interface, but not what the facts are supposed to be. The docs.puppetlabs.com site tries to say what all of the facts are, but it ends up being pretty vague in a lot of cases ( http://docs.puppetlabs.com/facter/1.6/core_facts.html). > >> Is there an actual documented API to refer to? If not, I don't think >> SemVer really helps us here - it becomes a matter of opinion as to what the >> implied API is. In my opinion, the implied API is that processorcount >> counts logical CPUs and currently gets it wrong on Solaris. >> > > SemVer is still useful even without a public API. it's just a lot more > difficult to make decisions like this one. > > All said, however, whatever SemVer says I think for purely practical >> reasons perhaps we should treat this as a backwards incompatible change. :) >> > > In this case I think we must release this in Facter 2 or figure out a way > to make it backwards compatible. > Given the vagueness of the 1.6 facts, I think we should aim to resolve this in 2.0, otherwise we'll just keep having this kind of conversation again and again. Does anyone want to take a stab at putting together clear, concise definitions of the core facts that would resolve these kinds of questions? There is the other question of guiding Facter to a 2.0 release. We just haven't had enough time to devote to it to make sure that it would be a release that truly advances us, but if anyone wants to give it a shot, speak up. > > -Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
