Fedora releases every six months, and the changelog between versions is usually long enough to warrant a proper read before upgrading. The 43-to-44 jump is no different — it touches the compiler stack, major language runtimes, desktop environments, how the installer handles networking, and how the system loads TLS certificates. Some of those changes are transparent; others will break existing workflows if you hit them unprepared.
Fedora 43 landed in October 2025 and pushed Wayland into mandatory territory, shipped Python 3.14, and completed the transition to DNF 5. Fedora 44 arrived in April 2026 and continued in the same direction — but added a new major GNOME release, a significant toolchain overhaul, Ruby 4.0, and several changes that directly affect how systems are installed and managed. On server and cloud setups, the storage and networking tweaks are worth paying attention to as well.
This article breaks down what actually changed between the two releases, which changes matter for which use cases, and how to upgrade safely — including what to watch out for before you reboot.
A Quick Note on How Fedora Works
Fedora operates on a roughly six-month release cycle and maintains two active versions at any given time. Each version receives updates for approximately 13 months — about one month past the next-next release. So when Fedora 44 ships, Fedora 43 stays supported but enters its wind-down phase, while Fedora 42 approaches end-of-life.
The project has a reputation for shipping upstream software fast — often faster than any other major distribution. What lands in Fedora today tends to show up in Red Hat Enterprise Linux a year or two later. This makes Fedora particularly attractive to developers who want a close-to-upstream experience without the chaos of a rolling release.
What Fedora 43 Introduced
To understand what Fedora 44 changes, it helps to know where 43 left things. The October 2025 release was notable for several reasons.
The most visible shift was GNOME 49, which arrived with one significant and non-negotiable constraint: X11 support was dropped entirely. Not reduced — removed. Wayland became the only supported display server for GNOME. The lock screen gained power controls and media playback support directly from it. Do Not Disturb moved to Quick Settings. HDR screen brightness controls appeared. The default video player switched to Showtime, and the document viewer to Papers.
On the system side, Fedora 43 completed the move to DNF 5 as the full package management stack and introduced RPM 6.0 with OpenPGP v6 signature support. Python 3.14 shipped with template string literals and notable performance improvements. The Anaconda web-based installer — introduced in Fedora 42 for Workstation — became the default for all official spins. The boot partition size requirement was raised to 2 GB to accommodate larger kernel images. KDE arrived with Plasma 6.4.5, which included solid Wayland support and updated widgets.
In short, Fedora 43 closed a chapter: it finished transitions that had been in progress for several releases. Fedora 44 opens a new one.
What's New in Fedora 44
GNOME 50 and the Desktop Environments
Fedora 44 Workstation ships with GNOME 50. This release doesn't chase a dramatic visual overhaul — the focus is on depth: accessibility gets genuine attention this cycle, color management becomes more consistent across applications, and remote desktop handling is substantially more reliable. The Digital Wellbeing section in Settings gains proper parental control tools: screen time scheduling and bedtime limits, without needing a third-party extension. The default application suite — Document Viewer, File Manager, Calendar — all landed updates with practical improvements rather than interface changes for their own sake.
One behavioral change that catches users off guard: middle-click paste is disabled by default in GNOME 50. If you rely on it for pasting clipboard content with the middle mouse button, re-enable it after the upgrade:
Alternatively, GNOME Tweaks exposes the same toggle in its interface. It's a small change, but common enough to mention before the upgrade.
For KDE users, Fedora 44 brings KDE Plasma 6.6. Two changes stand out immediately. First, SDDM is no longer the default display manager — it's replaced by the new Plasma Login Manager, which integrates more tightly with the Plasma stack. Second, a Plasma Setup application now guides users through initial configuration on first boot, making the out-of-box experience significantly more cohesive. This brings KDE's onboarding closer to what GNOME has offered for years.
Budgie also makes the Wayland-only jump in this release. Budgie 10.10 migrates fully from X11 to Wayland, laying the groundwork for the next major Budgie release. The Fedora Games Lab drops Xfce in favour of KDE Plasma 6.6, a move driven by Wayland's better handling of input latency and screen tearing — both of which matter more in games than in a typical desktop workflow. On the more exotic end, Fedora 44 adds a KDE Mobile Spin for x86-64 and select Arm64 tablets.
Developer Toolchain Updates
This is where Fedora 44 makes the biggest leap for anyone compiling or building software.
The GNU toolchain received a full update: GCC 16.1, binutils 2.46, glibc 2.43, and GDB 16.3. GCC 16 brings new optimization capabilities and stricter defaults — some code that compiled cleanly under GCC 14 or 15 may now produce warnings or errors, particularly around undefined behavior and missing prototypes. On the positive side, "undefined reference" build failures caused by missing new symbols are largely resolved.
LLVM jumps to version 22, keeping Fedora current with the upstream Clang and LLVM ecosystem.
Ruby makes the biggest language version jump of this release: Ruby 4.0 replaces Ruby 3.4 from Fedora 43. This is a major version change. Ruby 4 brings new features and improvements, but also removes some deprecated APIs. Any project relying on behavior that was soft-deprecated in 3.x may need adjustments before running cleanly.
Go advances to 1.26, continuing Fedora's practice of tracking closely to the current upstream release. PHP reaches 8.5. CMake jumps from 3.31 to 4.2 — a significant version bump that breaks compatibility for projects specifying cmake_minimum_required with a lower bound below 3.5. Additionally, the default generator for the %cmake macro changes from make to ninja, which affects how packages are built. Maintainers and developers building from source should verify their projects still compile correctly.
For infrastructure and automation work: Ansible 13 replaces Ansible 11, bringing Ansible Core 2.20 along with it. The most consequential internal change is in the Jinja2 templating engine, which tightened validation in several areas that previously produced wrong output without raising an error. Playbooks that happened to work despite containing incorrect template logic will now stop and report a failure instead — which is the correct behavior, but means something that "passed" on Fedora 43 may not on 44. Porting guidance is available in the Ansible 13 release documentation and is worth reading before running automation against an upgraded system.
Helm 4 is now the default helm package. Upstream made deliberate API breaks between Helm 3 and Helm 4, so existing charts and release workflows may need adjustments. For Kubernetes setups that aren't ready to migrate, a separate helm3 package can be installed alongside Helm 4 — both coexist without conflict. Similarly, Django advances to 6.x while a python3-django5 package stays available for projects not yet ready to move.
System and Package Management Changes
PackageKit switches to a new DNF5 backend built on libdnf5, which completes the package management migration that Fedora 43 began. Most users won't notice this directly, but it improves consistency between graphical software tools (like GNOME Software) and the command-line dnf workflow.
Anaconda changes how it handles network device profiles on fresh installs. The old behavior created a NetworkManager profile for every detected wired interface, regardless of whether you actually configured it during setup. That approach worked, but left a mess of auto-generated profiles that complicated any post-install network reconfiguration. Going forward, Anaconda only writes profiles for interfaces you explicitly touched — via boot options, kickstart, or the interactive installer UI. Everything else stays unconfigured until you set it up yourself. For server deployments where networking is typically provisioned by automation after the OS is laid down, this is a meaningful improvement.
TLS certificate handling gets a performance and structural overhaul. The ca-certificates package now organises certificate data using a hash-indexed directory layout, which cuts the time OpenSSL spends scanning for trusted CAs on startup. The practical side effect: /etc/pki/tls/cert.pem is gone — the file simply isn't generated anymore. Any script or service that opens that path directly, rather than going through the system's CA lookup API, will hit a missing-file error after the upgrade. It's a quiet failure mode, worth auditing before you reboot into Fedora 44.
Fedora 44 adds a packaged version of the Nix package manager (along with its commercial offshoot Flox). This doesn't make Fedora a NixOS variant — RPM remains the foundation. What it means practically is that Nix enthusiasts can install it natively and manage their own Nix-packaged software within their home directory, without compromising the system package set.
On the cloud and storage side, Cloud images that support it now use a Btrfs subvolume for /boot instead of a separate partition. This reduces image size and makes space allocation more flexible. Stratis 3.9.0 is also included, a notable release for Red Hat's next-generation storage management stack.
Podman 6 ships as the default container runtime. For teams that rely on Podman for local container workflows or rootless builds, this is worth factoring in when planning the upgrade — especially if tooling around Podman is version-pinned.
NTSYNC: Better Windows Application Compatibility
Fedora 44 enables the NTSYNC kernel module for packages that benefit from it — most notably Wine and Steam. NTSYNC is a kernel synchronization mechanism that improves how Linux handles Windows-style threading primitives, which translates to better compatibility and performance when running Windows applications and games.
The way it works in practice: when Wine or Steam is installed, the wine-ntsync package is pulled in as a recommendation, which automatically configures NTSYNC on subsequent boots. Users don't need to manually enable anything. For anyone who uses Fedora as a gaming platform or runs Windows software through Wine, this is one of the more practically useful additions in this release.
Architecture and Hardware
For ARM64 users, Fedora 44 includes automatic DTB selection for aarch64 EFI systems. The live ISO now auto-selects the correct Device Tree Binary when booting from EFI on Windows-on-ARM laptops — no manual configuration needed. This is a meaningful quality-of-life improvement for developers testing on Surface Pro 8 and similar hardware.
The new livesys-scripts framework enables persistent overlays when a Fedora live ISO is written to USB. Changes made in live mode — installed drivers, Wi-Fi passwords, configuration tweaks — survive a reboot without rebuilding the image from scratch.
QEMU drops 32-bit host builds (i686). The QEMU project has been phasing out i686 build support in preparation for internal refactoring that requires 64-bit host assumptions throughout the codebase — keeping 32-bit alive would mean maintaining a fork of that architecture indefinitely. Fedora follows suit here rather than carry the maintenance burden alone. FUSE 2 libraries and binaries are also removed from all Atomic Desktops.
Fedora 43 vs Fedora 44: Side-by-Side Comparison
| Component | Fedora 43 | Fedora 44 |
|---|---|---|
| Release date | October 28, 2025 | April 2026 |
| GNOME | GNOME 49 (Wayland-only) | GNOME 50 (Digital Wellbeing, parental controls) |
| KDE Plasma | Plasma 6.4.5 | Plasma 6.6 (new login manager, Plasma Setup) |
| Linux Kernel | 6.17 | 6.19 |
| GCC | GCC 14 | GCC 16.1 |
| LLVM | LLVM 19 | LLVM 22 |
| Python | Python 3.14 | Python 3.14 (continued) |
| Ruby | Ruby 3.4 | Ruby 4.0 |
| Go | Go 1.25 | Go 1.26 |
| PHP | PHP 8.4 | PHP 8.5 |
| MariaDB | MariaDB 10.11 default | MariaDB 11.8 default |
| CMake | CMake 3.31 | CMake 4.2 (make → ninja default) |
| Ansible | Ansible 11 / Core 2.18 | Ansible 13 / Core 2.20 |
| Helm | Helm 3 | Helm 4 (helm3 available in parallel) |
| Network profiles | Created for all detected devices | Only for devices configured during install |
| Nix package manager | Not included | Packaged and available |
| QEMU i686 | Supported | Dropped |
| Podman | Podman 5 | Podman 6 |
| NTSYNC (Wine/Steam) | Not available | Enabled via package recommendation |
| Cloud /boot | Separate partition | Btrfs subvolume (where supported) |
Who Should Upgrade — and When
The answer depends less on the release itself and more on what you actually run on the machine. Here's how the risk-benefit calculation changes by use case.
Desktop developers
If you write Ruby, the upgrade decision is immediate and important. Ruby 4.0 is a major version — gems and applications that relied on deprecated 3.x behavior may fail on startup without changes. The same applies if you maintain projects that use CMake: the jump to version 4.2 and the switch to ninja as the default generator can break builds that previously worked. Test in a VM or on a non-primary machine before committing to the upgrade on your main workstation.
Go and Python projects are generally low-risk. Go 1.26 maintains the standard compatibility guarantees. Python stays at 3.14, so nothing changes there from Fedora 43.
KDE and Budgie users
Fedora 44 delivers the most substantial KDE update in this cycle. The new Plasma Login Manager replaces SDDM, and the Plasma Setup application streamlines first-boot configuration. If you're running KDE and it matters to you, this is a solid release to move to. Worth noting: users with existing KDE installs who want the new login manager or desktop setup flow need to install them manually — they don't arrive automatically on upgrade.
Server and cloud operators
The changes to Anaconda's network profile behavior matter here. If your provisioning scripts or automation assumed that Anaconda would create profiles for all network devices, they may need adjusting on freshly installed Fedora 44 systems. The Btrfs /boot change for cloud images affects disk layout, which could matter for snapshot or backup tooling that inspects partition layout. For teams running Ansible automation, Ansible 13's stricter templating engine is the most likely source of surprises — review existing playbooks before deploying on 44.
Teams using Kubernetes with Helm
Helm 4 ships as the default, but the helm3 package is installable in parallel. There's no need to rush the migration; the coexistence approach gives you time to test your charts and releases against Helm 4 before cutting over. The smart path is to install helm3 after upgrading, keep using it for existing clusters, and start testing against Helm 4 on a staging environment.
Casual desktop users
For anyone who primarily browses, streams, writes, and uses standard applications, Fedora 44 is a smooth upgrade. GNOME 50 doesn't break anything from GNOME 49. The desktop feels visually similar, and the improvements — parental controls, better color management, refined apps — are additive. The upgrade process through GNOME Software or the terminal is straightforward and similar to any regular system update.
How to Upgrade from Fedora 43 to Fedora 44
The recommended path is dnf system-upgrade. The plugin downloads all packages first, then applies them during a dedicated offline reboot phase — nothing gets installed while the system is running. Run these four commands in order:
sudo dnf upgrade --refresh
# Step 2: Install the upgrade plugin (if not already installed)
sudo dnf install dnf-plugin-system-upgrade
# Step 3: Download the Fedora 44 packages
sudo dnf system-upgrade download --releasever=44
# Step 4: Trigger the upgrade (system will reboot and apply packages)
sudo dnf system-upgrade reboot
After the last command, the machine reboots into upgrade mode and works through the package list on its own. How long this takes depends on connection speed and how many packages are installed — a few minutes on a minimal server, considerably longer on a full desktop setup with many third-party packages.
If you have TeXLive installed from Fedora 43, remove it before upgrading. The modular packaging changes in TeXLive 2025 can cause the upgrade to fail if the old packages are still present:
sudo dnf clean all
If you use TLP for power management, it's worth removing it before the upgrade and re-evaluating afterward. Fedora 44's default power management stack has matured significantly, and TLP can occasionally conflict with the system upgrade process:
sudo systemctl disable tlp
sudo dnf remove tlp tlp-rdw
GNOME Software also supports upgrades through the interface — a notification appears once Fedora 44 is available in your region's mirrors. For straightforward configurations this path works fine, but it gives less feedback when something goes sideways. If a repository conflict or package removal triggers a warning, the terminal version surfaces it with an actual error message; the GUI typically does not. On systems with NVIDIA proprietary drivers or unusual repo setups, the terminal route is safer.
Testing Fedora 44 Changes in a Cloud Environment
Not everyone wants to risk a production or primary workstation for testing a major version upgrade. A common approach is to validate the new toolchain, verify that Ansible playbooks run correctly against Fedora 44, or reproduce a dependency issue — all on a throwaway cloud instance before touching anything that matters.
Serverspace doesn't offer Fedora images, but several of its available distributions are useful for adjacent testing scenarios. AlmaLinux on Serverspace is a practical target if you're checking RHEL-compatible behavior alongside Fedora changes — AlmaLinux tracks closely to the same upstream packages that Red Hat eventually pulls from Fedora. Ubuntu instances work well for cross-distro CI comparisons. If your workflow involves container images or toolchain output that needs to run somewhere beyond your local machine, a VPS lets you spin up a clean environment, run the tests, and discard it — without disrupting the Fedora upgrade on the workstation.
Common Mistakes When Upgrading
A few things consistently trip people up when going from one Fedora version to another.
Not updating the current system first. Running dnf system-upgrade download against a partially-updated Fedora 43 leaves old package versions in the mix, which raises the chance of dependency conflicts mid-download. Run sudo dnf upgrade --refresh and reboot before touching the upgrade commands.
Ignoring third-party repositories. RPM Fusion, COPR repos, and vendor-specific repositories sometimes lag a few days behind the Fedora release. A blocked package from one of them will stop the entire download step. Before starting, list your active repos with dnf repolist and note which ones are non-Fedora. If one causes a conflict, use --disablerepo=name on the download command, finish the upgrade, and re-enable it once the maintainer pushes Fedora 44 builds. When removing a conflicting package is the only option and you understand what you're losing, --allowerasing can help — but read what dnf proposes to remove before confirming.
Upgrading while running the graphical session for a complex setup. GNOME Software handles it fine for most users, but on systems with NVIDIA proprietary drivers or unusual hardware configurations, upgrading from the command line in a non-graphical target reduces the risk of driver conflicts during the reboot phase. The akmod mechanism that compiles NVIDIA modules needs time after the first reboot — don't panic if the display behaves oddly immediately after the upgrade finishes.
Running Ruby applications without testing first. Ruby 4.0 is a major version. If you host Ruby applications on the same machine, the upgrade will switch the system Ruby. Test your applications in a separate environment first, or use a version manager like RVM or rbenv to isolate the application runtime from the system Ruby.
Not reviewing Ansible playbooks before running them on upgraded systems. Ansible 13 tightened the templating engine in ways that expose bugs that were previously masked. A playbook that produced correct-looking output on Fedora 43 can fail at the same task on 44 — not because the system broke, but because a real logic error is now caught instead of quietly skipped. Check the Ansible 13 porting guide before deploying automation on upgraded machines.
Hardcoded TLS certificate paths. The /etc/pki/tls/cert.pem file is removed in Fedora 44 as part of the OpenSSL certificate handling overhaul. Scripts, services, or custom applications that reference this path directly will stop working after the upgrade without producing an obvious error. Audit anything that handles TLS manually before upgrading, and update paths to use the system CA bundle directory instead.
Upgrading a dual-boot system without verifying GRUB. Some users have reported that the upgrade process can affect GRUB configuration for other operating systems on dual-boot setups. Back up GRUB configuration before starting, and verify other OS entries are intact after the upgrade completes.
Advantages and Disadvantages of Upgrading Now
Fedora 43 continues to receive security and bug-fix updates, so there's no immediate pressure if you're in a stable production environment. The realistic picture looks like this:
Reasons to upgrade promptly: GNOME 50 and Plasma 6.6 are genuinely better than their predecessors. The GCC 16.1 toolchain catches more bugs at compile time. Ruby 4.0 brings new language features worth using. Go 1.26 keeps your Go environment current. The Ansible 13 hardening, while it may break some playbooks initially, makes automation more reliable long-term. If you write Helm charts, starting to test against Helm 4 now gives you time to migrate before Helm 3 goes out of active support.
Reasons to wait a few weeks: Early-release Fedora installations sometimes surface issues that weren't caught in the beta — driver compatibility problems, unusual hardware behavior, package conflicts in specific configurations. Waiting a month after release lets the community identify and fix those edge cases. If your system is dual-booting, the GRUB risk is worth taking seriously. If you depend on TeXLive and haven't removed it, that's a blocker that needs addressing before upgrading.
Conclusion
Fedora 44 is a substantive release. GCC 16.1, Ruby 4.0, CMake 4.2, Ansible 13, and Helm 4 all carry real migration work for anyone who depends on them. The Anaconda networking change and the removal of /etc/pki/tls/cert.pem are the kind of quiet system-level shifts that cause post-upgrade confusion if you don't know they happened. On the desktop side, GNOME 50 and Plasma 6.6 are both polished releases worth moving to.
The upgrade process with dnf system-upgrade is reliable — the Fedora project has refined it across many release cycles. Preparation is what determines whether it goes smoothly: update the current system fully, remove TeXLive beforehand if installed, audit TLS-sensitive scripts, and keep a snapshot or backup before the reboot. Those steps take thirty minutes; recovering from an avoidable failure takes considerably longer.
Fedora 43 stays supported for the foreseeable future, so there is no urgency for stable systems. For development machines and environments where staying close to upstream matters, Fedora 44 is ready.
FAQ
Yes. Fedora maintains two active releases at a time. Fedora 43 continues to receive updates for approximately one month after Fedora 45 ships, giving you time to upgrade without urgency.
Skipping a major version is not officially supported. The recommended path is Fedora 42 → 43 → 44. Attempting to jump two versions increases the risk of dependency conflicts and broken packages.
Proprietary NVIDIA drivers from RPM Fusion should work, but they need to be recompiled for the new kernel via akmod. If the graphical session doesn't load immediately after the upgrade, wait a few minutes or reboot once more — the akmod process sometimes needs a second boot to complete. Avoid upgrading from within a live graphical session if possible.
GNOME 50 and KDE Plasma 6.6 both run exclusively on Wayland. Most applications work well. Some older applications that rely on X11 directly can still run through XWayland, which remains available. Applications that refuse to work at all without X11 are increasingly rare, but they do exist — check your specific tools before committing to the upgrade.
If you have an existing MariaDB installation, the upgrade from Fedora 43 to 44 does not automatically change your running database version. Only fresh installs using the unversioned default package are affected — they now get MariaDB 11.8 instead of 10.11. Existing installations keep their current version unless you explicitly install the new default.
Downgrading between Fedora major versions is not officially supported and is generally impractical once the upgrade is applied. If rollback capability is important for your setup, take a full system snapshot or backup before upgrading — on a VM this is straightforward with most hypervisors.
No. After upgrading to Fedora 44, install the helm3 package alongside the new Helm 4 default. Both can be installed at the same time. You can take as long as you need to test your charts against Helm 4 before switching over.