The six-month clock
You install Fedora 41 in January. By July, the package manager starts warning you about a new version. By October, your repositories stop updating entirely. The timeline feels arbitrary until you understand the cadence. Fedora ships a new major release every six months. The cycle is strict, automated, and completely independent of feature readiness. The project does not wait for a kernel to be perfect or a desktop environment to be polished. The release schedule is a calendar event.
This cadence dictates everything about how you maintain the system. It determines when your repositories go dark, when you must run a major upgrade, and which versions you can safely run in production. The six-month window is not a suggestion. It is a hard boundary enforced by the mirror infrastructure and the package signing keys.
Plan your maintenance around the calendar, not around the software. Reboot before you debug. Half the time the symptom is gone.
How the release pipeline actually works
Development happens continuously in a branch called Rawhide. Every commit that passes basic build checks lands there. Rawhide is the bleeding-edge development track. Packages are rebuilt daily. Dependencies shift constantly. The system is designed to break so developers can catch regressions before they reach users.
After a few weeks of active development, the team freezes the package set and cuts a Beta release. Beta runs for roughly four weeks while testers file bugs and developers patch critical issues. The freeze prevents new features from entering the branch. Only security fixes and critical bug patches are allowed through. On the scheduled date, the Beta becomes the official Stable release. The previous stable version immediately drops to the N-1 tier. The version before that, N-2, enters its final support window.
This model means you are always running software that was frozen six to twelve months ago relative to the absolute latest commits. That is intentional. Stability comes from a known package set, not from chasing the newest git hash. Think of it like a train schedule. The train leaves at fixed intervals. You can board at any station, but you cannot change the departure time.
Fedora's release cadence is 6 months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle.
Checking your position on the timeline
You need to know exactly where you sit on the timeline before you run any upgrade commands. The package manager does not guess your intent. It follows the repository metadata. The metadata contains the releasever variable, which tells dnf which version tree to download packages from. If that variable is stale, the transaction fails.
Here is how to check your current version and release status.
rpm -q fedora-release # Returns the exact package version, e.g., fedora-release-41-1.fc41.noarch
cat /etc/os-release # Shows PRETTY_NAME and VERSION_ID for script compatibility
dnf repolist enabled # Lists active repositories and their base URLs
The output tells you two things. The major number tells you which release cycle you are on. The repository URLs tell you whether you are pointing at stable mirrors or development branches. If you are on Fedora 40 and Fedora 42 just shipped, your system is at N-2. The mirrors will stop serving updates for Fedora 40 within days. You must upgrade to Fedora 41 or 42 before the repositories go dark.
You can also check the exact EOL date for your current version without leaving the terminal. The release metadata includes a metadata_expire field and the Fedora project publishes a public schedule. Running the version query against the official release tracker confirms whether you are still in the supported window.
Trust the package manager. Manual file edits drift, snapshots stay.
Performing the upgrade correctly
Upgrading within a release uses the standard package manager. Upgrading across releases requires a dedicated tool. They are not interchangeable. Point releases (like 41.1 to 41.2) only update packages within the same version tree. Major releases (like 41 to 42) replace the base system, rewrite configuration defaults, and update the bootloader.
Here is the correct command for routine maintenance within a release.
sudo dnf upgrade --refresh # Forces metadata download to catch newly published packages
sudo dnf autoremove # Cleans up dependencies that are no longer required by installed packages
sudo dnf clean all # Clears cached metadata to prevent stale package lists
dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Here is the correct command for crossing major release boundaries.
sudo dnf system-upgrade download --releasever=42 # Fetches the new release tree without modifying the current system
sudo dnf system-upgrade reboot # Commits the transaction and restarts into the new version
The download phase is critical. It resolves all dependencies for the target version while the current system remains untouched. If the download fails, your running system is completely safe. The reboot phase applies the transaction. The package manager replaces core libraries, updates the kernel, and runs post-install scripts. The process takes longer than a normal reboot. Do not interrupt it.
A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
Verifying the switch and catching drift
After a point release update or a major version jump, you need confirmation that the system actually switched tracks. Do not assume the reboot finished cleanly. The package manager may have skipped packages due to conflicts or held back updates due to missing dependencies.
Here is how to verify the new release is active and the repositories are pointing to the correct metadata.
rpm -q fedora-release # Should match the target version you just upgraded to
dnf repolist enabled # Base URLs must now contain the new release number
journalctl -b -p 3 # Checks the current boot for critical errors or failed services
If the repository URLs still show the old version number, your transaction did not complete. The system is running in a mixed state. Roll back immediately or restore from a snapshot. You should also verify that the bootloader configuration matches the new kernel. The grub2-mkconfig script runs automatically during the upgrade, but custom entries can sometimes persist.
Run journalctl -xe first. Read the actual error before guessing.
Common failure modes and exact error strings
The most common mistake is running dnf upgrade when you actually need dnf system-upgrade. The package manager will refuse to cross version boundaries with the standard command. It will print a dependency resolution failure that looks like a broken repository.
Error:
Problem: package fedora-release-42-1.fc42.noarch requires fedora-release-common = 42, but none of the providers can be installed
The conflict is intentional. The standard upgrade path does not rewrite the base configuration files or handle the bootloader transition. You must use the system-upgrade plugin. Another frequent issue is ignoring the EOL cutoff. When a release hits end of life, the mirrors archive the packages. The package manager will fail to fetch metadata and drop you into a broken state.
Curl error (6): Could not resolve host: download.fedoraproject.org
This is not a network failure. The repository path no longer exists on the live mirrors. You need to upgrade before the cutoff date or switch to the archive mirrors manually. SELinux context mismatches also appear frequently after major upgrades. Old configuration files may retain the wrong security context, causing services to refuse to start.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Which track matches your workflow
Use Rawhide when you are testing packages that have not yet landed in a stable branch and you can afford daily breakage. Use Beta when you want to validate hardware compatibility and report bugs before the official launch. Use Stable when you need a predictable environment for daily work or production services. Stay on the upstream Workstation if you only deviate from the defaults occasionally. Upgrade to N+1 when N-2 reaches end of life and the mirrors go dark.
Snapshot the system before the upgrade. Future-you will thank you.