Fedora Release
Introduction
This assume you have a working setup already. See the other documents
(e.g. the one using Docker to get a development environment working) to get
set up. Also, if using a container-based environment, ensure that the image
you’re using reflects the latest |
This document guides you through updating the websites for a release (beta or GA) of Fedora.
Most of the work comes down to editing one file,
sites/getfedora.org/release.yaml
. What follows are the important points to
note.
The release.yaml
file is broken into several main sections, and the
relevant ones are ga
, beta
, fmw
, and gpg_keys
.
Pushing to the |
Beta Releases
If you are updating for a beta release, then you are free to leave the
ga
section alone.
In the beta
section, you’ll want show
to be true
. This toggles whether
we show the beta download links at all. It also changes the banner at the
top of the website to announce the beta instead of the previous GA
release. The announcement_release_number
dictates which version number is
shown in that announcement, so you’ll want to bump it to the beta version
being released.
Next you’ll want to edit the editions
section, still under the beta
parent section. Bump the release_number
and set the rc_version
to the RC
that was called gold/ready for release. Find this information out from
releng, if necessary.
GA Releases
If you are updating for a ga release, then in the beta
section, set
show
to false
, so that the beta downloads don’t show, and the
announcement at the top of the landing site reflects the new GA. Check with
someone (usually Paul Frields (stickster
on IRC) to find the URL of the
Fedora Magazine announcement for the release, and set announcement_url
to
that, in the ga
section.
Next, bump the release_number
and rc_version
of each edition under
editions
, using the rc_version
that was declared gold/ready for
release. Find this information out from releng, if necessary.
releases.json
file
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:
fmw:
...
releases_json:
- 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.
Checksum Files
You’ll need to import the checksum files into
sites/getfedora.org/static/checksums/
. To find out which checksums you
need to import, you can simply do a build of getfedora.org, and it will
error out and tell you what is missing. This is by design to ensure we don’t
miss a checksum file.
GPG Keys
Lastly, you’ll want to add the latest GPG key information to gpg_keys
in
release.yaml
. Follow the pattern that is already there, and move any
now-EOL releases into the obsolete
subsection.
Import any new GPG keys into sites/getfedora.org/static/keys/
, naming the
file [short key id].txt
e.g. 57BBCCBA.txt
.