On Podman 6 and weeding out legacy

 June 25, 2026

Podman 6.0 was released yesterday. This is a fairly big and important release, since they removed the support for cgroups v1, iptables, CNI, slirp4netns, and BoltDB. All features that depend on those dependencies have not been dropped; they are only supporting the modern replacements that have been available and the defaults for a while. In fact, they are now provided by cgroups v2, nftables, Netavark, Pasta, and SQLite, respectively.

I have been running Podman on my personal infrastructure for a few years now, mostly using Quadlet to manage services through Systemd. Personally, I do not envision any impact for me, since I already use all the new alternatives. Similarly, all other Fedora users should have a fairly smooth upgrade, unless they forced any of the removed options in their config, which should be very rare.

I think it is interesting that some of those (like cgroups v1) have been deprecated and unused by default for more than 6 years, and only now they have been dropped for good. Removing deprecated components from a project is always very hard. There is always someone still using the old path, and some of those will complain. Therefore, the natural tendency is to keep supporting deprecated features indefinitely.

The problem with keeping features indefinitely is that legacy code paths accumulate over time, making the code less and less maintainable. All those code paths will need to be tested, will constrain new features, and will confuse new developers and users. At some point, carrying them is more expensive than removing them. Furthermore, with the tools available today, it is possible to quickly scan large codebases for security vulnerabilities, and the more code an application has, the more likely it is that some vulnerability is present.

Though it is important to remove code properly, start by creating an alternative path, providing a few releases to test it, making it the default, waiting for more releases, and only then evaluating how to remove it completely. On this point, the Podman team acted very responsibly, providing guidance to their users for many years and, wherever possible, providing code to simplify the process.

There is a tendency to treat backward compatibility as always required, but I would argue it is a trade-off like any other. The cost of maintaining backward compatibility is paid in complexity, which, in turn, leads to slower development and security vulnerabilities. This does not mean that every developer will be able to do it quickly, but I think every developer should focus on this aspect and ask themselves what they can drop today and how they can drop even more code in the foreseeable future.