Darren Reed wrote: > For people outside ON, I'd contend that Consolidation Private is the > same as Project Private.
And all that means is "warning - implementation detail ahead, not intended to be used as an interface into this functionality!" Nothing here about secret or forbidden; the implication is that if you choose to make a dependency on this detail, you will have to /react/ when it changes, rather than being part of the proactive "think before doing" regime we try to use. Inside of ON, this is "business as usual" - you change something and you are *expected* to ferret out and fix all the internal-to-ON consumers of the thing you changed, even if/when the thing you changed was Private. This is hard, which is why we have variations on the Private theme - shared among friends private, shared among close family private and only shared with my spouse private :-) The only thing that changes in FOSS-ON is the pool of developers in the friends and family buckets gets a bit larger, not that our classifications or expectations change drastically. The difference between *Private and Volatile is the scope of closure; when you change your *Private interface, we expect you to be able to fix the closure of ALL dependencies as you integrate; with a public exposure like Volatile, you can't, and there *will* be consumers who get burned. Bottom line for me: If it *is* an implementation detail, *Private is the right answer. If it is a new intended-to-be-public experiment, then it shouldn't remain *Private very long, because (other than being an oxymoron) private public things always seem to cause us problems. -John
