On 25/01/2026 12:46, Marek Greško via dovecot wrote:
Hello,
it may be true the change was announced long time before, but me personally
also did not notice and was quite surprised. If there is such a big
compatibility change I would expoect major version number change (3.0) not a
minor (2.4) which evokes some higher progress but not the configuration
compatibility change.
I would also expect on such change if the software accepts also old config for
some time and logs about deprecated config. Just to get prepared. I accept
there could be reasons which did not allow authors to do it like that.
Marek
Hi Marek
I don't want to underestimate people's irritation and surprise about
finding incompatible changes in Dovecot after upgrading a distro that
includes 2.4. If I had done the same thing I would also be irritated,
just maybe more with myself.
It's a good point about the major versioning, I am sure there is a logic
behind why Dovecot CE did a minor version update and Dovecot Pro did a
major one, linked to the amount of change that went into Dovecot Pro.
For those using Dovecot CE the amount of change they see between 2.3 and
2.4 could have warranted a major release too. But now that can only be a
lesson for the future.
Even if Dovecot CE had been released as 4.0 you would still find people
who have the strategy of doing the upgrade and fixing things afterwards.
Everyone has their own level of risk they are prepared to accept. I
admit to using that strategy on my desktop (after a backup) and it has
never let me down so far, but the risk is there.
When you have a production environment that cannot accept major down
time, you become more risk-averse. It may not be possible to read the
release notes of all packages updated in a distro upgrade, but based on
the purpose of the server (web server, db server, mail server, dns
server etc) I would certainly want to read release notes for the
packages that provide the key services.
In any case as I recently found out breaking changes is not ust a
problem related only to distro upgrades, even a simple package update
without changing distro version can have potentially disasterous
consequences (a dud version of mariadb distributed in the fedora 42
updates, that went into core dump at startup). So if you need to
guarantee a service level in production, any changes will always go
through a non production environment first. If you have a greater
acceptance of risks, then you can do an in place upgrades reading the
release notes of the key packages, or if you don't really mind about the
risks you can use the strategy of upgrade and see what happens. No one
strategy will fit all cases.
This may sound provocative, but the assumption that there is no risk in
just hitting the upgrade button, because the developers have named the
versions in a certain way, that if they changed the configuration they
must have done it in a backward compatible way, or they did it gradually
with deprecation notices over many releases (like mysql/mariadb, php,
which have another release and update logic) or they provided an
automatic migration script etc. just does not correspond with reality in
some cases like this one.
John
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
