Fedora release process

This page describes the end-to-end Fedora release lifecycle: how development in Rawhide becomes a branched release, passes through freeze milestones and validation, and is published to mirrors. For the mechanics of how composes are built, see Compose generation.

At each stage, the same toolchain connects the phases together. Maintainers land changes in dist-git; Koji builds and signs RPMs; Pungi (via nightly.sh or release-candidate scripts) assembles compose trees and kicks off image builds through Kiwi and Lorax; Fedora QA tests the resulting compose; Go/No-Go meetings decide whether to ship; RelEng signs and stages artifacts; and MirrorManager propagates the release globally.

Release schedule

Every Fedora release follows a published task schedule with dates for mass rebuild, branching, freezes, Go/No-Go meetings, mirror bit-flips, and end-of-life of the previous release. The RelEng view lists every task in order with start and end dates.

The schedule is the source of truth for when each phase below happens. This page describes what happens at each phase and which tools are involved. Dates shift between releases; always check the schedule for the release you are working on.

Key RelEng milestones on the schedule include:

  • Mass rebuild and mass branching

  • Post-branch freeze and Bodhi updates-testing activation

  • Beta freeze, Beta Go/No-Go, Beta staging, and mirror bit-flip

  • Final freeze, Final Go/No-Go, GA staging, and mirror bit-flip

  • Post-release cleanup and EOL of the previous release

Rawhide: rolling development

Rawhide is Fedora’s rolling development branch. All new work lands here first: package updates, feature changes, and toolchain updates submitted by maintainers through dist-git and built in Koji against the f45 tags.

Every day, a cron job on the compose infrastructure runs nightly.sh, which invokes Pungi to produce a new Rawhide compose. Output appears under /compose/rawhide, with latest-Fedora-Rawhide pointing at the newest tree. After the compose completes, nightly.sh rsyncs content to /pub/fedora/linux/development/rawhide and related paths, sends fedora-messaging notifications, and emails a compose report to devel@lists.fedoraproject.org.

Rawhide composes are fully automated and ungated: they reflect whatever successfully built in Koji at compose time, including broken dependencies where they exist. This makes Rawhide the primary integration point for the distribution during development.

To watch a compose in progress, open pungi.global.log for the current latest-Fedora-Rawhide tree.

Mass rebuild

Before branching a new Fedora release, the distribution typically undergoes a mass rebuild of Rawhide. The goal is to rebuild all packages against the current toolchain and dependency set so the branched release starts from a consistent base.

Mass rebuilds are scheduled and approved by FESCo and RelEng. RelEng creates a dedicated Koji side tag and build target, runs rebuild scripts from releng/tooling, and monitors progress across primary and secondary architectures. See Mass Rebuild SOP for the full procedure.

During a mass rebuild, Koji is the active component: Pungi composes continue on their normal schedule but reflect the churn of ongoing rebuilds until the rebuild completes.

Mass branching

At the scheduled branch point, RelEng cuts a new release branch from Rawhide. The branched release (for example Fedora 44) enters stabilization mode while Rawhide advances to the next version number.

Mass branching touches every layer of the stack:

  • dist-git branches are created for all active packages

  • Koji release tags, inheritance, and build targets are set up

  • Bodhi releases and repository links are configured

  • pungi-fedora, spin-kickstarts, fedora-comps, and related repos are branched

  • Signing keys are rotated: Rawhide packages are re-signed with the next release key

  • Compose cron jobs are updated for both Rawhide and the new branched release

See Mass Branching SOP and Mass Branching Checklist for step-by-step instructions.

After branching, two parallel development streams exist. Rawhide continues as the integration branch for the next Fedora version. The branched release receives targeted fixes and milestone composes leading toward GA.

Freeze phases

Once branched, the pending release passes through a series of freezes that progressively limit what can change in the compose trees used for milestone validation.

Feature freeze

The Feature Freeze stops acceptance of new feature changes in the branched release. At this point the String Freeze also takes effect. New builds for the branched release require a freeze exception approved through the blocker review process.

Koji tag policies tighten: the branched release tag is locked against casual updates, and Bodhi is configured for the frozen release state. RelEng avoids infrastructure changes that could affect the frozen compose during this period.

Beta freeze

Two weeks after mass branching, at 14:00 UTC, the Beta Freeze begins. The branched Koji tag is locked, Bodhi is set to frozen, and updates-testing is activated for the new release. From this point, only approved updates reach the branched compose trees.

Final freeze

The Final Freeze begins two weeks before the scheduled GA date, also at 14:00 UTC. The release tag is fully locked, retired packages are blocked in Koji, and only blocker fixes and approved freeze exceptions may enter the candidate composes.

During Beta and Final freeze, RelEng continues Rawhide composes and ELN work as normal. Changes to Ansible, Koji policy, or signing infrastructure that could affect the frozen release require explicit freeze-break approval.

Milestone composes

Milestone composes differ from Rawhide nightlies in how they are triggered, what Koji tags they draw from, and what labels they carry.

Rawhide nightlies

Rawhide composes run automatically via cron, use fedora.conf, and produce trees named like Fedora-Rawhide-YYYYMMDD.n.N. They pull from the latest successful builds in the Rawhide Koji tags with no freeze enforcement. See Rawhide composes for details.

Branched development composes

After mass branching, branched composes run on a schedule similar to Rawhide but use branch-specific pungi-fedora configuration (for example fedora-branched.conf). These composes land under kojipkgs.fedoraproject.org/compose/<BRANCH>/ and feed daily integration testing of the pending release.

Beta and Release Candidate composes

Beta and Final (GA) Release Candidate composes are not automated. Quality Engineering requests them by opening a ticket in releng/tickets. RelEng prepares a candidate configuration with create-candidate-configs.py, tags specific builds into the f*-compose Koji tag, and runs release-candidate.sh.

Each milestone differs in its compose label and Koji tag snapshot:

Milestone Config file Compose label example

Beta RC

fedora-beta.conf

Beta-1.5

Final RC

fedora-final.conf

RC-1.3

Candidate composes draw from the frozen tag set rather than live Rawhide, and the global_release version in the candidate config increments with each respin (for example 1.1 to 1.2).

See Beta RC Compose SOP and Final RC Compose SOP for the operational steps.

Go/No-Go process

Before each public milestone (Beta and Final), Fedora QA runs the release validation test matrix against the nominated Release Candidate compose. Open blocker bugs are reviewed; any bug that blocks release criteria must be fixed or waived before the meeting votes Go.

The Go/No-Go meeting is chaired by Fedora Program Management with representatives from QA, RelEng, Development, and other stakeholders. If the vote is Go, RelEng proceeds with staging and release per the Beta Release SOP or Final Release SOP. If the vote is No-Go, QE and RelEng coordinate a respin: updated builds are tagged, a new RC compose is produced, and validation runs again.

A No-Go respin requires a new candidate compose with an incremented global_release minor version. Do not stage a compose for public release until Go/No-Go approves that specific compose ID.

Signing and mirroring

All official Fedora artifacts are GPG-signed through RelEng’s signing infrastructure (robosignatory and Sigul). RPMs are signed automatically as they move through Koji tags; compose images and CHECKSUM files are signed during the staging process before any public push.

After a Go vote, RelEng stages the approved compose on mirror master using scripts from releng/tooling:

  1. Run stage_release_checksum_sign.sh to sign CHECKSUM files

  2. Run stage_release.sh to copy the compose tree to /pub/alt/stage/

  3. Verify signing completed successfully

  4. Perform the mirror "bit-flip" to move staged content to the live release path

  5. Notify mirror-admin@lists.fedoraproject.org with directory size figures

If signing fails at any point, do not push content to mirrors. Unsigned or partially signed trees must be fixed and re-signed before publication.

See Sign the packages and Compose signing for more detail.

Once the bit-flip completes, MirrorManager redirects download URLs to the new release, and mirrors worldwide begin syncing the tree.

Release announcement

Publication is coordinated with Fedora Marketing and CommOps after mirror propagation is confirmed. RelEng verifies that the staged tree is visible on a representative mirror before the announcement goes out.

For Beta and Final releases, Bodhi release state moves to pending at staging time and to current on release day. Torrents are created per Torrent Releases SOP. Marketing and the Docs team handle release notes and announcement copy.

Post-release

After GA, the release enters its maintenance period.

Updates through Bodhi

Package updates for the stable release flow through Bodhi. Maintainers submit updates to updates-testing; after sufficient testing and approval, RelEng or Bodhi’s automated compose pushes them to the stable updates repository. See Pushing Updates and the Updates Policy.

Koji image-builder and kiwi targets are repointed to f*-updates-candidate so that future image rebuilds draw from the stable updates tree rather than the frozen GA compose.

End of life

When a Fedora release reaches end of life, RelEng runs the End Of Life SOP: Bodhi and Koji tags are closed, mirrors are updated, and the release is marked EOL in project metadata. Post-Release Cleanup covers housekeeping after GA.

Ongoing Rawhide and branched work

Rawhide nightlies continue throughout. The newly released version becomes the "current" stable release; the previous branched release may receive its final update push before EOL. RelEng also handles ongoing tasks such as orphan package retirement (Retire Orphaned Packages), critpath updates, and EPEL branching where applicable.

Toolchain summary by phase

Phase Primary tools

Daily development

dist-git → Koji (build, sign) → Pungi → Kiwi/Lorax

Mass rebuild

Koji side tags, releng tooling rebuild scripts

Mass branching

dist-git branching, Koji tag creation, Bodhi, Ansible, pungi-fedora branching

Freeze milestones

Koji tag locks, Bodhi frozen state, blocked retired packages

RC composes

Pungi (release-candidate.sh), Koji compose tags, QE validation

Go/No-Go

QA test matrix, blocker review, RelEng staging scripts

Publication

Sigul/robosignatory signing, MirrorManager, torrents

Post-release

Bodhi updates, Koji target repointing, EOL procedures

Want to help? Learn how to contribute to Fedora Docs ›