You can see the announcements at https://archlinux.org/. The most recent is from June:

> Starting with libxcrypt 4.4.21, weak password hashes (such as MD5 and SHA1) are no longer accepted for new passwords. Users that still have their passwords stored with a weak hash will be asked to update their password on their next login.If the login just fails (for example from display manager) switch to a virtual terminal (Ctrl-Alt-F2) and log in there once.

I wasn't affected. The next one before that was February, and also didn't affect me.

I think I could count the number of such planned manual interventions that have affected me in the 6 years I've been running Arch on my laptop on the fingers of one hand. It's approximately the number of times I would have had to reinstall my OS from scratch in that time on most other distros, based on extensive prior experience of whole distro version upgrades messing things up in mysterious ways. I put this down to the rolling release and the arch devs not being lulled onto assuming everyone's running a fresh, pristine installation.

I have a 6 year old, heavily used (including for work), heavily customised development laptop I have installed the OS on exactly once, and I have absolutely no reason to contemplate starting again from scratch. It's bang up to date and rock solid. You'd have to pry Arch from my cold, dead fingers.

Looking through the latest advisories of upgrades requiring manual intervention, those mostly seem to be files that were mishandled. I guess they want to avoid "being smart" and trying to second guess the system setup.

Other distributions attempt to migrate the config / tools which mostly works, except when it doesn't. Earlier today I upgraded an Ubuntu 21.04 to 21.10. The computer is a glorified Spotify Connect player, so I don't configure anything on it. But for some reason, after the reboot, there's some issue with gvfsd-something-or-other. I never configured anything related to that. Is this normal / expected? No idea. A quick search on the release notes [0] yields nothing.

So I guess there are always tradeoffs. Arch seems to adopt more of a hands-off approach, where you only get a basic system and then you build your own environment. As such, there's many possible variations. In contrast to Ubuntu / Fedora / etc, where the devs can reasonably expect that a system is in a roughly known state.

[0] https://discourse.ubuntu.com/t/impish-indri-release-notes/21...

Well, manual interventions are rare [0] and almost all of them nowadays are due to the odd package restructuring. Usually the package manager will notify you about a conflict between two packages and won't proceed (so nothing will break). At this point you can check the website if there is a need to force install a package or two.

Although definitely more technical than most distributions the perceived difficulty of Arch is mostly a meme at this point. The last large possibly-system-breaking change was almost 10 years ago [1]. And even then, the solution was quite trivial. Now if you are forcing updates that conflict without reading the news then you're in for a bad time, but that's true for all distributions. In general pacman is very conservative and won't leave your system partially updated. Now there is a chance upstream updates break things, but that's the nature of the rolling release model.

Manual compilations are not necessary if you stick to the official repositories. If you need a package in the AUR then a ports-like setup is required. I have packaged stuff for both RPM and DEB-based distributions, nothing really beats the simplicity and flexiblity of the Archlinux packaging tools.

[0]: https://archlinux.org/news/

[1]: https://archlinux.org/news/the-lib-directory-becomes-a-symli...

It's the philosophy of Arch to stick to vanilla as much as possible and keep things simple. It's a rolling distro too with no fixed release cycles. When you upgrade fedora, ubuntu, etc. they perform various scripts to migrate existing configuration. In Arch, it just simply installs the vanilla packages whenever you tell pacman to update. Very rarely there is some breaking change, maybe once or twice a year, that requires manual intervention. Yeah they could automate it all but such stuff takes effort and breaks in other ways.

Because many of the changes are large enough that it will break, and that's expected.

The KISS principle applies here.

If a config file format changes in a service between version 3 and version 4, should the package manager be responsible for it? Or the admin?

Sometimes it's not just merging changes in.

In a non-rolling release distribution, you only need to worry about those changes during major upgrades. In a rolling release distro, they can change at any time. It's no different than a user reading the release notes for Debian 11 while upgrading from 10, except the upgrades are constant.

For one, not putting every single edge case into the package manager makes the behaviour of the package manager easier to understand.

Pacman now tells you when there is an announcement in the website. Most of this announcements are due some issue introduced in a package. I haven't faced all of them as usually they resolved quickly and when I update the system the new packages solves the issue. Rarely there has been a breaking change in a package that needed some easy manual intervention. I have maybe done this line 5 or 6 times in 15 years. Compared to Ubuntu, I find it upgrading process more tedious (I haven't tried it in the last year's so maybe now is better). Said that, probably i won't use arch for a production environment and stick to Ubuntu, but for home/work system, I love it

They announce (known) breaking changes that may require manual intervention. Meanwhile, when my ubuntu upgrade breaks something there is never any release notes or documentation to help me fix it. After my previous ubuntu upgrade at work, the screen locker is segfaulting instead of locking my screen, and clicking links inside the Slack crashes slack...

You can either deal with it once in while or you could let it pile up for years and then when a new major release comes up, you could spend days troubleshooting or reinstalling from scratch.

I think either method is fine, depending on the circumstances. Your choice.

Upstream breaks your stuff, you roll into the incompatible release, getting to fix it yourself.

There's no fixed release schedule that promises total compatibility at the cost of running years old releases.