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
Odoslané pomocou bezpečného emailu Proton Mail.
sobota 24. januára 2026, 17:13, John Fawcett via dovecot <dovecot@dovecot.org> napísal/a:
On 24/01/2026 14:10, Curtis J Blank via dovecot wrote:
I just did a Tumbleweed upgrade. then I had to fix dovecot. No warning that dovecot was going to break what so ever. Below is all the things I had to fix. And then I could not read my email in Thunderbird because you changed:
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u to mail_driver = mbox mail_path = ~/mail mail_inbox_path = /var/spool/mail/%{user}
and the "%u" to "%{user}" was the showstopper.
What a crock of BS! I spent 3 hours determining the problem and then fixing dovecot because you decided to make major changes for no good reason. It worked just fine the way it was. You could have automated the changes by providing a utility that would make the changes the first time it started up after the upgrade.
Hi Curtis
I understand the unexpected difficulty that you had to go through when you found the new version of Dovecot upgraded in your distro upgrade. But it has to be said that the 2.4 version has been a long time coming and is now at 2.4.2 and you can say many things, but the incompatible changes have been well known and publicized for a very long time now, I think probably years rather than months. If you're using Dovecot it would be best to keep an eye on announcements. Even if you hadn't noticed it, this didn't just come out of the blue.
I personally am still running the previous version on Fedora 42 and since the upgrade to 43 includes the new 2.4 I have made my own 2.3 rpms for Fedora 43 so that I can keep running it and then do the config conversion calmly and in a test environment before doing it for real, while still getting the new version of the distro. That strategy itself is not without risk though.
I can't blame distro packagers either. Some people are going to want the newest version, some people are going to be reticent about breaking their configurations and about the stabilization of the new version. You can't reallly please everyone.
The need for a configuration upgrade utility was probably clear to most people, but if it hasn't been done I think it is partly due to the difficultly of that task. it would have to cover many configuration parameters, not just the ones that you had to change in your case. Also some incompatible changes are not managed just through configuration. Depending on what features you currently use there could be some decisions to be taken too. I started to do some config migrations already on the previous installation for some of those features that were being deprecated in the new version just to hopefully smooth the final migration.
My guess is that so far no one has thought that it would be quicker to write a configuration utility than actually do the changes relevant to their own configuration. But that is the beauty of open source software. If you see a gap for something and you have the skills you can contribute something back and improve things for other people.
John
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org