Re: A proposal...
> Yes, exactly correct. We have three "contracts" to keep that I think aligns very well with the following semver "contracts":
> Major => API/ABI compatibility for modules
> Minor => Feature and directives
> Patch => Functional and configuration syntax guarantees
> Demonstrating by way of a few examples:
> If we add a directive but do not change exported structure, that would result in a minor bump since the directive is part of the feature set that would necessitate a config change to use (not forward compatible).
I don't agree that adding directives is adding function, in terms of
versioning or user expectations. I don't see why it a new directive
or parameter should necessarily wait for a new minor release
especially when there's so much sensitivity to behavior changes. It
> If we were to fix a security bug that does not impact running configs, that would be a patch bump since a config that works today must work tomorrow for the same maj.min.
> If we were to change default behavior, we would bump minor. This is because although the change doesn't break existing explicit configs of the directive, it would modify behavior due to implicit defaults => a visible change in functionality.
I think it is more illustrative to turn this around and say certain
changes must wait for a minor or major release.
To me the case worth enumerating is what tolerance for behavior change
we want to allow for a security fix that goes into a patch release.
> In all cases, the changelog would clearly state the changes and we would ship what we consider to be the best default config.
I'm not understanding the "best default config" part. Is this a way to
illustrate the stuff with bad hard-coded default values that won't be
fixed until the next minor? I think the term you're using is a little
broad/abstract for something like that.