Fedora Release (Modern)


This assume you have a working setup already. See the fedoraproject.org repository for instructions.

This document guides you through updating the websites for a release (beta or GA) of Fedora.

Make sure your changes are made on the develop branch. Staging & prod environment can then be updated with standard Merge Request.

Releases information

First, you need to edit the release.yml file either directly from git, or using the CMS (recommended). If you are updating for a beta release, then make sure to flip the "Display Beta Download" toggle in the CMS, or set the beta.enabled flag in the release.yml file to true.

This toggles whether we show the beta download links at all.

Bump the release version and set the release candidate version to the RC that was called gold/ready for release. Find this information out from releng, if necessary.

For GA release, you’ll need to update the Release Date and the Fedora Magazine announcement post as well.

Cloud AMI list

You’ll need to update the Fedora Cloud AMI list using the fetch_amis.py script:

./fetch_amis.py ../content/release.yml ../content/editions/cloud/ami_list.yml

The AMI list will be updated in /content/editions/cloud/ami_list.yml. Add that file to your commit.

Fedora Media Writer

TODO: Update this section for the new fedoraproject.org website

The next step is to produce the releases.json static file used by Fedora Media Writer to produce its list of possible downloads. In the fmw section of release.yaml, update the releases_json list to include the current non-EOL versions of Fedora, including any current betas. If a version is in beta, set the its milestone to beta. Otherwise set it to final or leave out the field altogether.

For example:

    - version: 31
      milestone: beta
    - version: 30
    - version: 29

Once this is done, you’ll need to actually generate the releases.json file.

If using a containerized environment, you can do this from the root of the repository (replacing sudo docker with podman if you use Podman):

sudo docker run -it --rm -v "$(pwd):/opt/:z" fedora-websites python ./scripts/releases-json.py > sites/getfedora.org/static/releases.json

Otherwise, if you’re not using a containerized environment, you can run the script yourself after installing the python-fedfind package. From the root of the repository:

python3 sites/getfedora.org/scripts/releases-json.py > sites/getfedora.org/static/releases.json

Check that releases.json looks sane (it should look like a blob of JSON), then move on.

GPG Keys

Lastly, you’ll want to add the latest GPG key information to gpg_keys in security.yml or with the CMS. Follow the pattern that is already there, and move any now-EOL releases into the obsolete subsection.

Release day

On release day (or the day before), you can check that all download links are good with the check_link.py script. This uses the release information from the release.yaml file.


Checking download artifacts...

[OK] https://dl.fedoraproject.org/pub/fedora/linux/releases/38/Cloud/aarch64/images/Fedora-Cloud-Base-38-1.6.aarch64.qcow2
[OK] https://dl.fedoraproject.org/pub/fedora/linux/releases/38/Cloud/aarch64/images/Fedora-Cloud-Base-38-1.6.aarch64.raw.xz
All Good!

If any artifact is flagged as missing, contact releng/infra team.


That should be all. The old sites (namely spins, labs, alt, arm) which haven’t been ported to the new system need to be updated separately and are beyond the scope of this document.

Commit your changes on the develop branch, make sure everything looks good on the GitLab pages, then use Merge Request to deploy to staging & prod.