Am 24.09.2014 um 16:29 schrieb Wietse Venema:
> The implementation will probably be a compatibility_level parameter
> that is 1 for installations that pre-date this feature, that is 2
> for new installations, and that is incremented by 1 for each
> compatibility break. People who don't care can set this to 999999
> and never hear a peep about compatibility breaks.
First of all, thanks for 15+ years of smooth Postfix rides.
Whenever I needed to give an example that smooth upgrades and
compatibility are possible, Postfix is the reference project.
A few thoughts on the deployment, more of practical matter:
1 - Is changing the default - even if only applied to fresh installs - a
case for calling the first Postfix release to flip the 3.0 so people
will lift their heads to see if they're walking into pitfalls?
2 - sorry, this thought has two preceding ones that will make it look
like legalese:
2a - from talking about anonymous "change requests" in my daytime
(non systems admin) job where most people need to ask back "what is
CR088A all about?";
2b - still trusting you to get us a proper document that nicely lists
all the incompatible changes that caused this integer to be bumped:
Do you think an integer serves the purpose? What happens if, despite
all good intention, due diligence and care, something that breaks
compatibility needs to be back ported? Would this want to be a set of
mnemonic flags or semantic version numbers instead?
3 - is there a useful way to log warnings about unqualified domains when
they are observed and qualified in mid-flight, so that people have
something to watch for before flipping the switch? It seems there
already is, check_{sender,recipient}_access + WARN action + regexp map -
so canonical information how to enable this ahead of time already now
might help smooth out the migration even more.
