Fedora Release (Modern)

Introduction

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 by using the information from the release.yml file edited in the previous step. Add that file to your commit.

Fedora Media Writer

The next step is to produce the releases.json static file used by Fedora Media Writer to produce its list of possible downloads.

Use the the build_fmw_release.py script to generate that JSON file with the release information from the release.yml file:

./build_fmw_release.py ../content/release.yml > ../public/releases.json

Check that the releases.json file looks sane and contains the newest release. Add that file to your commit.

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.

./check_link.py

Checking download artifacts...

Cloud:
[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.

Conclusion

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.

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