Am 24.04.2018 um 19:58 schrieb Daniel Ruggeri:
On 2018-04-24 09:22, Eric Covener wrote:
On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr
<wr...@rowe-clan.net> wrote:
On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener <cove...@gmail.com> wrote:
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.
As a general rule, adding a directive introduces a new feature, along
with new functions, and structure additions.
I won't argue the semantics any further, but I don't agree there is
any such equivalence or general rule.
One thing you mention above is "wait for a new minor release". I can
definitely see that being an issue for our current maj.minor layout
given that minor bumps are measured in years. In this proposal, unless
there's a pressing need to send out a patch release right now, the next
version WOULD be that minor bump. Put into practice, I would see major
bumps being measured in years, minor bumps in quarters and patch bumps
in weeks/months.
For me including this would poison almost any proposal it is added to.
In the context above: I want to use directives for opt-in of fixes in
a patch release.
FWIW, I propose that a directive addition would be a minor bump because
directives are part of a configuration "contract" with users - a set of
directives that exist in that major.minor. By adding directives in a
patch, we break the contract that would state "Any configuration valid
in 3.4.x will always be valid in 3.4.x." We can't do that today, but it
would be great if we could. Adding directives only in a minor bump
provides a clean point at which a known set of directives are valid.
When directives control new features, I would totally agree. An example
that might be harder to decide, was the security hardening a little ago
where the parsing of lines was made much stricter. For security reasons
this became the default, but for interoperability with broken clients we
allowed the strict parser to get switched off by a new directive.
It was a security patch, so should become part of a patch release, but
due to changed behavior, the directive would also be needed for people
who prefer old behavior over enhanced security.
If we would argue, that that hardening was a big enough change to only
include it in a minor release, then we must be aware, that people could
only use this security enhanced version by also getting all of the other
new features in that version, which is typically not what you want when
you update just for security reasons.
Regards,
Rainer
