> 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 seems backwards. > 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.
