Fedora Release (Modern)

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

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.

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

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

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:

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):

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:

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

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.

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.

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.