git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proposal...


On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener <covener@xxxxxxxxx> 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.

If someone says "try the WizBang directive", it is much clearer if this
appears in 2.7.0 and stays there without being renamed or dropped
until some future minor release. So we can claim the docs apply to
version major.minor with no confusion about the set of features in
this 2.7 flavor of Apache. 3-6 months later, some version 2.8 might
up and change those, but we can be careful about not making any
gratuitous changes without offering some back-compat support of
older directive names. (E.g. NameVirtualHost could have been a
no-op directive for a considerable time with no harm to the user's
config or intent.)