The openSUSE Project released Leap 16.1 on 3 November 2026, the first minor update in the Leap 16 series. The headline is not a version bump on the desktop, though Plasma users do get one. It is a structural change: Leap Micro, the project's separate immutable server distribution, no longer ships on its own. It lives inside Leap now, as Immutable Mode, selectable from the same install image as a traditional system. One distribution, two ways of running it, and the choice you make at install time now matters more than the version number.

What Immutable Mode actually changes

On a traditional Leap install, updates write straight into the running system. On an Immutable Mode install, the root filesystem is read-only and every update goes through transactional-update, which builds a new snapshot and boots into it. If the update breaks something, one command rolls the system back. Updates become something you can undo, instead of something you have to debug at 2 a.m.

The trade-off is real. Extra software on an immutable system comes through containers with Podman or Distrobox, or through Flatpak on the desktop, rather than packages installed directly onto the root. If your workflow is "install whatever, edit system files by hand, recompile a driver on a whim," the traditional install stays the better fit. If the box is a server, container host, or edge device that should survive a bad update unattended, Immutable Mode is the interesting one. It is the same approach Leap Micro users already know, now sharing Leap's release, lifecycle, and maintenance updates instead of tracking a separate product line. There will be no Leap Micro 6.3 or 7.0.

Picking a side: a short decision guide

Choose Traditional if this is your daily desktop, you rely on third-party repositories, or you regularly install software that expects to live on the system itself. Choose Immutable Mode if the machine's job is defined and stable, uptime matters more than tinkering, and you want every update to come with a built-in undo button. For a laptop you customize constantly, traditional is still the honest answer.

The upgrade paths

From Leap 16.0: this is the easy one. The documented path is a distribution upgrade with zypper --releasever 16.1 dup, after refreshing repositories. Third-party repositories need attention on any dup: re-point or re-add them for 16.1 before you declare the upgrade finished, and check that packages you got from outside the main repos survived the switch.

From Leap 15: jump straight to 16.1 rather than stopping at 16.0. The openSUSE migration tool offers 16.1 as a target, and going to 16.0 first only buys you a second distribution upgrade later. Note the baseline change: Leap 16 requires x86-64-v2 as the minimum CPU level, so very old hardware needs a different plan, and the project points those users at Slowroll or Tumbleweed.

From Leap Micro 6.2: existing Micro systems can move to Leap 16.1 in Immutable Mode with the openSUSE migration tool, but the project calls this path experimental. Make a backup first, and report how it went. Before any of these paths, take a real backup, not just a snapshot: our Timeshift backup guide covers the full-disk safety net, and the snapshot mindset behind Immutable Mode is the same one in our btrfs snapshots playbook.

What else is new

Desktop users get KDE Plasma 6.6 with Qt 6.11 and KDE Frameworks 6.25, up from Plasma 6.4. GNOME stays on 48 with maintenance updates, LXQt moves to 2.4, Xfce on Wayland continues with 4.20, and LibreOffice 26.2 and GIMP 3.2 arrive for office and creative work. Under the hood, 16.1 keeps Linux kernel 6.12, systemd 257, and glibc 2.40, with QEMU 11.0, libvirt 12.4, Podman 5.8, Python 3.14 alongside the default 3.13, LLVM 21, PHP 8.5.12, MariaDB 12.3, and PostgreSQL 18. The Agama installer is now at version 24, SELinux remains the default security module, and annual minor releases are planned through Leap 16.6 in 2031.

One correction worth noting

The original announcement claimed Leap 16.1 shipped on the same day as SUSE Linux Enterprise Server 16.1. openSUSE has since corrected that: SLES 16.1 is expected later in November, not on release day. The synchronization argument still stands once SLES lands, but the same-day claim itself was wrong, and the correction is printed at the top of the announcement. Leap keeps source and binary identicality with SLES, and users can still migrate from Leap to SLES when a workload outgrows community support.

Leap 16.1 is not a release that asks you to relearn your distribution. It asks you to make one decision you did not have to make before: traditional, or immutable. Make it deliberately, match it to the machine's job, and the rest of the upgrade is routine. Our Fedora 45 upgrade playbook is a useful rehearsal for the same discipline: backup, snapshot, upgrade, verify, and only then clean up.

Sources

  • openSUSE Project, "Leap 16.1 Unites Traditional and Immutable Linux in One Release", openSUSE News, 3 November 2026 (including the published correction on SLES 16.1 timing)
  • openSUSE Project, Leap 16.1 release announcement, openSUSE mailing list, 3 November 2026
  • DistroWatch, "Distribution Release: openSUSE 16.1", 3 November 2026