Profile config strategy

[Cantor, Scott]

On 12/12/13, 2:43 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>It seems that profile configuration properties _should_ be in the API
>since those are the knobs that users tweak.

Yes, if we think of API in the broad/complete sense. I don't argue that
point.

In my case, much less so than in Java, the cost of breaking the ABI (not
API, but the binary interface) simply to add a configuration setting is
intolerable.

In this case, I don't fully grok the impact or trade-offs. I do know we
would, if we follow our policy, be forced to do a minor version change in
response to a new property. That seems excessive to me, but maybe not to
others.

(Not saying it wouldn't normally or commonly be a minor version bump, but
that's different than "must be".)

> The class hierarchy seems to fit the rest of the Java code, along with
>the "hardwired" classes,
>by which I assume you mean getProxyCount() instead of
>get("ProxyCount").

Yeah (allowing that clearly they'd be constants, unlike my sloppy in the
extreme code in the SP, which I never went back and symbolic'd).

>I guess, at a high level, adding a config property is an API change,
>minor rather than major, though.

Yes. And if you argue, defensibly, that even a change to the API in the
sense that doesn't involve a change to an interface or class should be a
minor version change, then clearly that issue is moot.

I haven't done that in the SP case.

>If we add a property to fix a bug, then incrementing a minor version
>seems appropriate.

If we think so, then I think it's really moot. It's formally an API change
regardless.

-- Scott