Fedora Final Release

Koji Changes

Lock the release tag:

$ koji edit-tag --lock f44

Update the image builder target to use the updates-candidate tag as the destination tag. This ensures that the f44-image-builder target will create images from the stable updates repository:

$ koji edit-target f44-image-builder --dest-tag f44-updates-candidate

This command is necessary to update the image builder target’s destination tag after the release has been finalized. It ensures that subsequent builds will use the updates-candidate tag as the destination, which is the appropriate tag post-release. Previously, the -updates-candidate tag was locked during the freeze process, so this must be updated after the final release.

Update the kiwi target as well due to the same reason:

$ koji edit-target f44-kiwi --dest-tag f44-updates-candidate

Bodhi Changes

Set the Bodhi release to current and add the release date:

$ bodhi releases edit --name F44 --state current --released_on YYYY-MM-DD
$ bodhi releases edit --name F44F --state current --released_on YYYY-MM-DD

Set the Bodhi stable tag to point to updates instead of the base repository:

$ bodhi releases edit --name F44 --stable-tag f44-updates

Atomic Desktops Changes

Run the relevant script on a compose machine with /mnt/koji mounted.

$ ./tooling/release-process/atomic/update_ostree_refs.sh 44

This updates the refs for Atomic desktops to have users follow updates for the new release rather than being stuck on the GA compose forever.

Ansible Changes

Update Relevant Variables

  1. Set FedoraCycleNumber to 44.

  2. Set FedoraPreviousPrevious to True.

  3. Set FedoraBranched to False.

  4. Set NextReleaseFrozen to False.

Now run the relevant playbooks:

$ sudo rbac-playbook groups/koji-hub.yml
$ sudo rbac-playbook groups/releng-compose.yml
$ sudo rbac-playbook openshift-apps/bodhi.yml -t all,rollout
$ sudo rbac-playbook groups/bodhi-backend.yml
$ sudo rbac-playbook openshift-apps/greenwave.yml -t all,rollout
$ sudo rbac-playbook groups/openqa.yml -t testcase_stats

If you do not have permissions to run a playbook, ask a sysadmin-main member for help. A sysadmin-qa member can run the openQA playbook.

Stage Final Release To Mirrors

To prepare for running the staging script, make sure you have the following information:

  1. Release Version: This is the numerical version number of the release, for example, 44.

  2. ComposeID: The ID associated with the Compose, such as "Fedora-44-20160614.0".

  3. Label: The label used for the location in stage, for example, "Compsoe label for the location in stage 39_RC-1.2."

  4. Key: The name of the release key, which can be "fedora-44" or "fedora-44-secondary," as examples.

  5. Prerelease: Set this to 0 or 1 to determine if the release should be placed in a testing environment or not.

  6. Arch (Optional): For secondary architectures, this parameter can be used to make changes to some internal locations.

    $ ./release-process/staging/stage_release.sh 44 Fedora-44-20160614.0 44_RC-1.2 fedora-44 0

  7. Sync the release to the Red Hat internal archive following internal documentation.

Make sure to grab the directory size usage numbers which is used to send an email to mirror-admin@lists.fedoraproject.org list.

Bodhi Tagging

Sometimes builds are not properly tagged during the freeze process. Make sure all builds are properly tagged. For more information about the issue, see this ticket.

Verification

Verification is somewhat difficult as one cannot look at the content via the web server due to permissions. Typically we ask somebody from the Infrastructure team to give the tree a second set of eyes.

Some things to check for:

  1. Are the CHECKSUM files signed?

  2. Are the spins/labs present?

Set EOL Date For Oldest Release

The EOL date for the oldest release is calculated like so:

"The N release EOL date is initially set as the Early Target Date + 5 weeks of the N+2 release. If the N+2 release slips past the Final Target Date #1, the N release EOL date is shifted in the same way."

In other words, if the new Fedora version is released before Final Target Date #1 then nothing needs to be done. In case there are delays, there are four places where the EOL has to be updated.

Bodhi

$ bodhi releases edit --name F42 --eol YYYY-MM-DD
$ bodhi releases edit --name F42C --eol YYYY-MM-DD
$ bodhi releases edit --name F42F --eol YYYY-MM-DD

Fedora Schedule

Ask the program manager to update the date in the schedule.

fedora-release

Update fedora-appstream-metadata.spec and org.fedoraproject.fedora.metainfo.xml with the correct values. Then open a PR, get it merged, do a build in Koji, and submit an update in Bodhi.

fedora-appstream-metadata

Update fedora-release.spec with the correct value. Then open a PR, get it merged, do a build in Koji, and submit an update in Bodhi.

Post-Release Tasks

One Week After The Release

In the first week after the release MirrorManager still uses the files in fedora/linux/development/<version> and not in fedora/linux/releases/<version>

Once enough mirrors have picked up the files in the release directory, run the following playbook from batcave to change the paths in MirrorManager:

$ rbac-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-devel-to-release.yml --extra-vars="version='44'"

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