> On Oct 26, 2021, at 4:54 PM, raf <post...@raf.org> wrote:
>
> On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
> <wie...@porcupine.org> wrote:
>
>> Vincent Pelletier:
>>> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
>>> Wietse Venema <wie...@porcupine.org> wrote :
>>>> This would require a new setting, for example to make smtp_bind_address
>>>> failures a retryable error.
>>>>
>>>> smtp_bind_address_failure_action = warn (or defer)
>>>>
>>>> warn: current behavior
>>>> defer: treat as a faiilure to connect
>>>
>>> This looks like something I would want to use in my situation. Does the
>>> implementation complexity and maintenance cost look reasonable to you,
>>> for what seems to be a rather niche use (otherwise someone else would
>>> certainly have done the same mistake before) ?
>>
>> It does not complicate the code. I am more concerned about
>> discoverability (how would a user even find out that the behavior
>> has become configurable).
>>
>> A popular approach in OSS is to enable incompatible changes by
>> default. I hate that.
I've wondered this for a while, and have even suggested the day job implement
this in our own software.
This feels like a reasonable place to ask. Is there a way, given a new warning
about compatibility_level (say you've been running with 3_5, and you're now
running 3_6), to see what changes to your config are effectively made by
enabling that level? (effectively, to show a defaults-diff, or any commands
whose behavior may not have the same meaning under a previous version)?
-Dan
